Re: A Challenge
* Nate Williams ([EMAIL PROTECTED]) [990910 07:14]: In any case, if you install a recent version of FreeBSD, I doubt Mr. NT is capable of crashing FreeBSD from externally. Just make sure he doesn't have an account on it, since it's much easier to cause Denial Of Service attacks if you don't spend alot of time setting up limits and such. Going even further than what Nate said, remove all accounts you don't need. Give only accounts to those who need to admin the box, other than that DO NOT give away accounts. Make sure the security log files sent by email are being sent to the correct persons. Remove /usr/src and compile kernels on a secondary host so you are sure that compiling stuff on the firewall is hard after a compromise. Use ssh and ditch telnet. read security(9) -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best If Winter comes, can Spring be far behind? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: submiting source code ?
* Gustavo V G C Rios ([EMAIL PROTECTED]) [990910 04:14]: I use freebsd about +- 12 months ago. I have never did any thing serious at kernel level, nor i know anything about kernel desgin. Start with: Modern Operating Systems by Andrew S. Tanenbaum The Design and Implementation of 4.4BSD by Marshall Kirk McKusick et al. Unix Internals: The New Frontiers Then you probably need more special in-depth books such as: TCP/IP Illustrated by (R.I.P.) W. Richard Stevens Unix Network Programming by W. Richard Stevens The Unix Programming Environment by Rob Pike and Ritchie Kerninghan Advanced Programming in the Unix Environment by W. Richard Stevens Suppose, i would like to spend time and patience learnig Fbsd internals. If, later, i were able to code something to freebsd, and suppose i do, what (or better, how) should i do to have my source accepted by the core team? send-pr after you have tested, style(9)'d, documented your code and tested you patches against a clean checked out source base. What about coding style ? As Chris said, style(9) What are the golden rules to have my sources widely accepted by freebsd community? Don't go the Linux way which tends to favor bloat over solid code. Portability and correctness of code is more important than features. PS: This is my first attempt to start touching the kernel, so, don't blame, if i wrote something wrong. That's ok, it's a long way before you actually will start touching the sources though, it involves a lot of RTFM'ing and UTSL'ing first. -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Workers of the world, unite! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NetWare client in -current
On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote: Growing up programming on a KL-10, I still think the correct place for line-editing is in the driver. Hell - it's already doing basic erase/kill line editing as it is. Then you don't have to hack every command-line app to get line-editing. Yeah, but how do you specify completion then? Unix went here a long time ago and backed out of it. Have a look at the paper http://www.cs.princeton.edu/~jlk/kornshell/doc/vhll.ps.gz (linked from www.kornshell.com) in particular, the history section. -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator "vi has two modes the one in which it beeps and the one in which it doesnt." -- Anon. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
"Rodney W. Grimes" [EMAIL PROTECTED] writes: No. The scrollback may be too short (especially after an fsck of a large filesystem after a crash), and it may even be empty (if you put something like VESA_132x60 in allscreens_flags in rc.conf) We can tune the size of the scroll back buffer can't we? Yes, but we don't want to increase the default size too much. And fsck output even after a crash is usually not that long, if it gets long it usually has more problems than fsck -p can deal with and stops any way. You've obviously never fsck'ed a largish soft-updated filesystem after a power outage. Why does switching display mode screw up the scroll back buffer? That sounds broken to me. Because you have to resize the scrollback to accomodate the new line width. You're welcome to fix it. I've tried, and decided that it was far from a SMOP and that it would have to wait until I have more than a few hours' continuous free time. Doesn't ntpdate log what it does with syslog? If you give it the -s option, yes it will syslog it. But doing that to everything in /etc/rc* seems like a pain in the *ss... Lazy people never achieve much. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
de0 strangenesses
On a 3.0-current of October 1998 I'm having often trouble with de0. The machine often reboots over night (when either the locate db is built or some other big job - like mirror - is running). Anyway, after the reboot, often de0 is dead. This happend today again. When I came into the office I could not ping said machine. I sat at the console, logged in. The machine was perfectly alive, only the de0 interface didn't work at the BNC network. I did a ifconfig de0 down and exactly with doing that I got a kernel message from the driver: de0 BNC interface enabled (or something like that). Doing an ifconfig de0 up right after that the interface continued working at the BNC port. Can the driver writer(s) comment whether there have been changes to the driver WRT that behaviour so I can expect that with either 3.2 or -current the problem would be gone? -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More press
Dirk GOUDERS [EMAIL PROTECTED] writes: Oh, sorry -- my "browse-url-at-mouse" function made http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242 c00.html of it... Netscape uses commans to separate parameters to the OpenURL command. Fortunately, the API is open and documented, so there's nothing to stop someone from writing a small command-line util that does the equivalent of "netscape -remote" except faster and better. Well, having read all of your remarks, I noticed, that emacs' lisp code "browse-url.el" causes the generation of http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242 c00.html instead of http://www.zdnet.com/zdtv/screensavers/answerstips/story/0%2c3656%2c2324624%2 c00.html I fixed that (little) problem on my machine and sent a bug-report. Now, I enjoy loading URLs containing commas :-) Dirk To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More press
On Sun, Sep 12, 1999 at 03:22:55PM +0200, Dag-Erling Smorgrav wrote: Dirk GOUDERS [EMAIL PROTECTED] writes: Oh, sorry -- my "browse-url-at-mouse" function made http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242c00.html of it... Netscape uses commans to separate parameters to the OpenURL command. Fortunately, the API is open and documented, so there's nothing to stop someone from writing a small command-line util that does the equivalent of "netscape -remote" except faster and better. If you follow the link from "netscape -help", you end up at: http://home.netscape.com/newsref/std/remote.c Which is a small C program to do just that. I really should turn it into a port... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator "vi has two modes the one in which it beeps and the one in which it doesnt." -- Anon. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More press
Dominic Mitchell [EMAIL PROTECTED] writes: If you follow the link from "netscape -help", you end up at: http://home.netscape.com/newsref/std/remote.c The page you attempted to access was not found on Netscape's web site. You may have typed its location incorrectly, or it may have been moved, deleted, or incorporated into another part of Netscape's site. To report a broken link, please send a message to feedback. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Problem with FreeBSD
Hello All. I try install FreeBSD on HP Vectra VA/200DT - Pentium Pro/128Mb-RAM/ Quantum Fireball CR 4.3Gb/CirrusLogic5446PCI PCI/NE2000. When I try install FreeBSD (I'm tried 3.2-release/3.3-19990909-rc/snapshot-4.0-19990827-current) i have some trouble. On second floppy (mfsroot.flp) before kernel setup, FreeBSD write "zf_read: error". After this, I configured kernel (i kept only fdc0, wdc0, atkbd0, sc0) and when system wrote "changing root device to fd0c" and after this "rootfs is 2880Kbyte compiled in MFS" system stilled and doesn't run install proces, but "Pause" key and scrolling was working. Best regards, Zherdev Anatoly [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No Subject
To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
"Rodney W. Grimes" wrote: It dawned on me what can be done. Look, we get all the kernel printf's from the dmesg output saved in a buffer and pull that out later with syslog, looks like we could just slip a pipe fitting into /dev/console that copies all it's output into the mesgbuf as well, until we smack it wth the ballpean and tell it to stop doing that (Either getty lanching the login: on ttyv0 could cause this, or something at the end of /etc/rc). What do you think of that idea? I think that's a fine idea, and it's a lot cleaner than mine for a number of reasons. Completely beyond me to code, but very nice from the design standpoint. Most of the time I could care less what /etc/rc spits out. However, in the past, I have had to go add sleep(###) calls in various spots in rc to that I could actually read some of the error output to figure out why something was failing. I wouldn't mind having all of the /etc/rc output sent to the message buffer (and /dev/console) until a getty is running on ttyv0. Or at least make it a boot option. If you are having problems, boot the kernel with "boot -l" in the boot loader. Now, adding an option doesn't help in the case of fsck suddenly generating a million lines of output during boot, since that might not be expected, but it does help some cases. And scrollback buffers and message buffers only help if you have enough memory to hold all of that information. Right now I have 3 FreeBSD machine. 1 has 192MB of RAM. I have the message buffer set to some very large value (because of some boot problem I bumped it up a lot), so I at least see all of the kernel messages that were generating during a boot. This helped me debug a couple of problems. The other two machines only have 16MB, so they still run with a standard message buffer (geez, I remember when 16MB was *A LOT*). Perhaps we need a "boot message buffer" (just eat up free memory minus some protected space that is reserved for letting /etc/rc run without swapping). Keep sending data to that buffer during the boot process, and just before going multi-user, dump it off to disk and free it. On a 16MB machine, that shouldn't be a problem. For those people still running FreeBSD machines on 4MB, that is another story, but even in those cases, I would bet you could still be able to record and store at least some of the /etc/rc output. Its been a few years since I've seen fsck generate a couple of megabytes of output, so I know it is possible, but I think this idea could work, and solve most peoples problem of fsck generating MANY pages of output that just scroll by. -Mike -- Mike Pritchard [EMAIL PROTECTED] or [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: How to prevent motd including os info
[I'm catching up on a bunch of FreeBSD mail since being out on vacation, so perhaps I've missed the essence of this thread..] I've also had the desire to capture the output produced when /etc/rc is run for all the reasons mentioned. I always thought that perhaps init would simply capture stdout on the other end of a pipe, and logically do the "tee" thing with it. In fact, couldn't init logically exec a sh /etc/rc | tee /tmp/rc-output when invoking /etc/rc? (Where to put the output would seem to be one of the more difficult choices since you don't start with a writable file system mounted anywhere..) Or perhaps init could capture the output on the end of a pipe and subsequently syslog it while it's echoing it to /dev/console. louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
L440GX+ Server Board
Hi list, I can't solve the problem yet. When I runnig the dmesg command, I have: --- da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST39140LW 1483 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST39140LW 1483 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) --- I did a test, changing only the SCSI disk, using the same motherboard (L440GX+). I ran the dmesg command again and I received: -- da0 at ahc0 bus 0 target 0 lun 0 da0: QUANTUM QM39100TD-SW N491 Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8683MB (17783250 512 byte sectors: 255H 63S/T 1106C) -- I realized that the quantum disk have a 80.000MB/s transfers. Does someone use a SEAGATE ST39140LW disk and have I/O problems? Regards, Luiz Morte. PS: Someone told me that vipw doens't have much I/O disk, but when I run it with 12000 accounts, my disk have a lot off access. On Sun, 22 Aug 1999, Luiz Morte da Costa Junior wrote: Hi all, I have a problem with a server running a FreeBSD 3.2. My Server has a L440GX+ Serber Board (intel), with network card 10/100, SCSI AIC 7896 (80MB/s), 2 SCSI disk with 9GB (80MB/s), 2 pentium III 450Mhz (not overclocked). The NIC and SCSI are onboard. I recompiled a kernel to SMP, and it worked. The server is ok, but when I run a comand with disk access (whith vipw or mysql), the performance of server goes down. My server stays very very very slow. If I use pine to read my messages, it doesn't work. When the comand finishes, the server stays "ok" again. I recompiled the kernel with "maxusers 128", but it doesn't work. My SCSI cable has a terminator and the scsi setup is ok (I think :) ). The dmesg command output is in attchmnt. I appreciate any help. []s, Luiz Morte da Costa Junior Analista de RedesE-mail: [EMAIL PROTECTED] Telefone: +55 19 754-2532Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: de0 strangenesses
Christoph Kukulies writes: On a 3.0-current of October 1998 I'm having often trouble with de0. The machine often reboots over night (when either the locate db is built or some other big job - like mirror - is running). Anyway, after the reboot, often de0 is dead. This happend today again. When I came into the office I could not ping said machine. I sat at the console, logged in. The machine was perfectly alive, only the de0 interface didn't work at the BNC network. I did a ifconfig de0 down and exactly with doing that I got a kernel message from the driver: de0 BNC interface enabled (or something like that). Doing an ifconfig de0 up right after that the interface continued working at the BNC port. Can the driver writer(s) comment whether there have been changes to the driver WRT that behaviour so I can expect that with either 3.2 or -current the problem would be gone? this is old problem - I have it in 2.2.7-RELEASE too -- Chris Christoph P. U. Kukulies [EMAIL PROTECTED] -- @BABOLO http://links.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: More Press
Date: Mon, 13 Sep 1999 10:31:51 +0100 From: Dominic Mitchell [EMAIL PROTECTED] Subject: Re: More press On Sun, Sep 12, 1999 at 03:22:55PM +0200, Dag-Erling Smorgrav wrote: Dirk GOUDERS [EMAIL PROTECTED] writes: Oh, sorry -- my "browse-url-at-mouse" function made http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242c0 0.html of it... Netscape uses commans to separate parameters to the OpenURL command. Fortunately, the API is open and documented, so there's nothing to stop someone from writing a small command-line util that does the equivalent of "netscape -remote" except faster and better. If you follow the link from "netscape -help", you end up at: http://home.netscape.com/newsref/std/remote.c Which is a small C program to do just that. I really should turn it into a port... If you haven't already, I've just about finished a port for this (it is pretty nifty). The only problem I have currently is that I have to fetch 2 files for the port (the file listed above, as well as http://home.netscape.com/newsref/std/vroot.h). Without making a separate port just for vroot.h, if there a way to have the port fetch 2 files? Should I just list it using PATCH_SITES/PATCHFILES even though it isn't really a patch? Other than that I have to write a few patches of my own (the netscape source segfaults if no command is given and apparently presumes netscape 1.1). If I can find out the answer to fetching the 2 files, I'll send-pr the port right away. Thanks, Kelly ~[EMAIL PROTECTED]~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: More Press
-Original Message- From: Josef Karthauser [mailto:[EMAIL PROTECTED]] Sent: Monday, September 13, 1999 10:57 AM To: Kelly Yancey Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: More Press On Mon, Sep 13, 1999 at 10:48:07AM -0400, Kelly Yancey wrote: If you haven't already, I've just about finished a port for this (it is pretty nifty). The only problem I have currently is that I have to fetch 2 files for the port (the file listed above, as well as http://home.netscape.com/newsref/std/vroot.h). Without making a separate port just for vroot.h, if there a way to have the port fetch 2 files? Should I just list it using PATCH_SITES/PATCHFILES even though it isn't really a patch? Other than that I have to write a few patches of my own (the netscape source segfaults if no command is given and apparently presumes netscape 1.1). If I can find out the answer to fetching the 2 files, I'll send-pr the port right away. Take a look at the XFree86 port in x11. That fetches two large tarballs, and therefore probably does the right thing. Bingo...that did the trick, port coming soon... Kelly ~[EMAIL PROTECTED]~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: More press
On Mon, Sep 13, 1999 at 07:59:03AM -0700, Duane H. Hesser wrote: You probably already have it, as /usr/src/contrib/global/gozilla/remote.c Blimey! -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator "vi has two modes the one in which it beeps and the one in which it doesnt." -- Anon. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
device driver interface
I am trying to understand how to integrate device drivers with the kernel. (this is my first crack at device drivers) I have a few books on device drivers but they are a little old and have a slightly different interface with the kernel than FreeBSD. I figured the best place to start would be to try to building one of the samples. So did I did /usr/share/examples/drivers/make_device_drivers.sh WDC. The script will attempt to build the kernel and I get the following errors: cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I/usr/include -DKERNEL -DVM_STACK -include opt_global.h -elf ../../i386/isa/WCD.c ../../i386/isa/WCD.c: In function `WCDattach': ../../i386/isa/WCD.c:137: `WCDintr' undeclared (first use this function) ../../i386/isa/WCD.c:137: (Each undeclared identifier is reported only once ../../i386/isa/WCD.c:137: for each function it appears in.) ../../i386/isa/WCD.c: At top level: ../../i386/isa/WCD.c:177: `WCDintr' used prior to declaration ../../i386/isa/WCD.c: In function `WCDintr': ../../i386/isa/WCD.c:178: warning: unused variable `scp' ../../i386/isa/WCD.c: At top level: ../../i386/isa/WCD.c:188: conflicting types for `WCDioctl' ../../i386/isa/WCD.c:30: previous declaration of `WCDioctl' ../../i386/isa/WCD.c: In function `WCDclose': ../../i386/isa/WCD.c:226: warning: unused variable `scp' ../../i386/isa/WCD.c: In function `WCDread': ../../i386/isa/WCD.c:250: dereferencing pointer to incomplete type ../../sys/libkern.h:57: warning: inlining failed in call to `min' ../../i386/isa/WCD.c:250: warning: called from here ../../i386/isa/WCD.c:251: warning: implicit declaration of function `uiomove' ../../i386/isa/WCD.c: In function `WCDwrite': ../../i386/isa/WCD.c:267: dereferencing pointer to incomplete type ../../i386/isa/WCD.c: At top level: ../../i386/isa/WCD.c:273: conflicting types for `WCDmmap' ../../i386/isa/WCD.c:31: previous declaration of `WCDmmap' ../../i386/isa/WCD.c: In function `WCDmmap': ../../i386/isa/WCD.c:275: warning: unused variable `scp' ../../i386/isa/WCD.c: In function `WCDpoll': ../../i386/isa/WCD.c:296: warning: unused variable `scp' ../../i386/isa/WCD.c: At top level: ../../i386/isa/WCD.c:177: warning: `WCDintr' defined but not used *** Error code 1 Why does this fail? This script was installed of off my 3.2 cd set. Does anyone know of an existing driver that would be a good place to start for a newbie to understand these things? Any and all help is appreciated, Wayne To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
Tony Finch [EMAIL PROTECTED] wrote:
Is there a reason for disallowing concurrent read-only mounts of the
same disk device? i.e. would things go pear-shaped if I added this
capability?
Well, in the absence of any comments I hacked around a bit and ended
up with the following patch (against 3.3-RC), which permits the same
block device to be mounted read-only more than once. The motivation
for this is to permit multiple chrooted environments to share the same
/usr partition.
Some things I wonder about this change is whether the mounts will share
the same pages in the buffer cache, and whether the resource
accounting is still right. I've subtly funted the meaning of
v_specmountpoint when multiple mounts happen; does this matter?
Tony.
--
f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix
--- /usr/src/sys/sys/fcntl.h.orig Mon Sep 13 15:21:29 1999
+++ /usr/src/sys/sys/fcntl.hMon Sep 13 17:04:46 1999
@@ -93,6 +93,7 @@
#defineFMARK 0x1000 /* mark during gc() */
#defineFDEFER 0x2000 /* defer for next gc pass */
#defineFHASLOCK0x4000 /* descriptor holds advisory lock */
+#defineFMOUNTING 0x8000 /* a block device is being mounted */
#endif
/* Defined by POSIX 1003.1; BSD default, but must be distinct from O_RDONLY. */
--- /usr/src/sys/miscfs/specfs/spec_vnops.c.origMon Sep 13 17:11:17 1999
+++ /usr/src/sys/miscfs/specfs/spec_vnops.c Mon Sep 13 15:37:22 1999
@@ -229,7 +229,7 @@
* Do not allow opens of block devices that are
* currently mounted.
*/
- error = vfs_mountedon(vp);
+ error = (ap-a_mode FMOUNTING) ? 0 : vfs_mountedon(vp);
if (error)
return (error);
return ((*bdevsw[maj]-d_open)(dev, ap-a_mode, S_IFBLK, p));
--- /usr/src/sys/kern/vfs_subr.c.orig Mon Sep 13 11:44:59 1999
+++ /usr/src/sys/kern/vfs_subr.cMon Sep 13 11:55:06 1999
@@ -1886,6 +1886,39 @@
simple_unlock(spechash_slock);
return (count);
}
+
+/*
+ * Calculate the total number of writers on a special device.
+ */
+int
+vwritecount(vp)
+ register struct vnode *vp;
+{
+ struct vnode *vq, *vnext;
+ int count;
+
+loop:
+ if ((vp-v_flag VALIASED) == 0)
+ return (vp-v_writecount);
+ simple_lock(spechash_slock);
+ for (count = 0, vq = *vp-v_hashchain; vq; vq = vnext) {
+ vnext = vq-v_specnext;
+ if (vq-v_rdev != vp-v_rdev || vq-v_type != vp-v_type)
+ continue;
+ /*
+* Alias, but not in use, so flush it out.
+*/
+ if (vq-v_writecount == 0 vq != vp) {
+ simple_unlock(spechash_slock);
+ vgone(vq);
+ goto loop;
+ }
+ count += vq-v_writecount;
+ }
+ simple_unlock(spechash_slock);
+ return (count);
+}
+
/*
* Print out a description of a vnode.
*/
--- /usr/src/sys/ufs/ffs/ffs_vfsops.c.orig Mon Sep 13 11:21:07 1999
+++ /usr/src/sys/ufs/ffs/ffs_vfsops.c Mon Sep 13 17:08:23 1999
@@ -586,28 +586,33 @@
struct ucred *cred;
u_int64_t maxfilesize; /* XXX */
size_t strsize;
- int ncount;
+ int ncount, nwritecount;
dev = devvp-v_rdev;
cred = p ? p-p_ucred : NOCRED;
+ ronly = (mp-mnt_flag MNT_RDONLY) != 0;
/*
-* Disallow multiple mounts of the same device.
+* Only allow multiple read-only mounts of the same device.
* Disallow mounting of a device that is currently in use
* (except for root, which might share swap device for miniroot).
* Flush out any old buffers remaining from a previous use.
*/
- error = vfs_mountedon(devvp);
+ error = ronly ? 0 : vfs_mountedon(devvp);
if (error)
return (error);
+ nwritecount = vwritecount(devvp);
+ if (nwritecount)
+ return (EBUSY);
ncount = vcount(devvp);
-
- if (ncount 1 devvp != rootvp)
+ if (!ronly ncount 1 devvp != rootvp)
return (EBUSY);
- vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
- error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
- VOP_UNLOCK(devvp, 0, p);
- if (error)
- return (error);
+ if (ncount = 1) {
+ vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
+ error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
+ VOP_UNLOCK(devvp, 0, p);
+ if (error)
+ return (error);
+ }
/*
* Only VMIO the backing device if the backing device is a real
@@ -622,8 +627,8 @@
VOP_UNLOCK(devvp, LK_INTERLOCK, p);
}
- ronly = (mp-mnt_flag
softupdates panic in 3.3-RC
Our ftp server crashed early this morning with what appears to be a softupdates error: Sep 13 09:56:19 stumble /kernel: pid 41477 (perl), uid 0 on /exports/share3/ftp/.2: file system full panic: softdep_write_inodeblock: indirect pointer #0 mismatch 0 != 15597568 syncing disks... panic: softdep_lock: locking against myself 'perl' would have been the nightly mirror(1) run to sync up our ftp site. What additional details would be usefull? We didn't have crashdumps enabled on this machine, so a backtrace is not fully possible, although it would seem the contextual evidence for what went wrong is strong. -- David Cross | email: [EMAIL PROTECTED] 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
subscribe
subscribe To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Let a daemon process print a message
syslog() with the proper facility is probably the best way to do this. Another possibility is opening /dev/console, but I think that will aquire a controlling terminal. On Mon, 13 Sep 1999, Zhihui Zhang wrote: Can anyone tell me how to let a daemon process print a message to the console? Adding printf() does not work (I wonder if a daemon process has been cut of relationship with stdout). Thanks for any help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- 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: more info Re: how did I manage this?
On Sun, Sep 12, 1999 at 12:29:55PM -0400, Wayne Cuddy wrote: rm '$DEST_DIR' rm: $DEST_DIR: is a directory ls '$DEST_DIR' $2 rm doesn't work on directories.. go for $ rm -rf '$DEST_DIR' or $ rm '$DEST_DIR'/'$2' $ rmdir '$DEST_DIR' regards, -Oscar -- For PGP Public Key: finger [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: damn ATX power supplies...
Just my 2 cents and a staple ... A staple bent properly and wedged in the crimp part of the pin between the green wire to a black wire does the trick for me. Now I turn that machine on via the power switch on the back of the power supply which ATX power supply people are now adding. I have a devel motherboard that I'm using without a manual and without a working on button. For more info just look at the various ATX spec's online. Doug A. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Let a daemon process print a message
Out of da blue Zhihui Zhang aka ([EMAIL PROTECTED]) said: On Mon, 13 Sep 1999, Brian Mitchell (ISSATL) wrote: syslog() with the proper facility is probably the best way to do this. Another possibility is opening /dev/console, but I think that will aquire a controlling terminal. On Mon, 13 Sep 1999, Zhihui Zhang wrote: Can anyone tell me how to let a daemon process print a message to the console? Adding printf() does not work (I wonder if a daemon process has been cut of relationship with stdout). Thanks for any help. I have tested syslog(). I find out: (1) The log messages will go into /var/log/messages and appear on the console only after I login in (as root). (2) The LOG_INFO priority does not cause the messages to appear on the console or to be written into file /var/log/messages. Can anyone explain the reason for me? Thanks a lot. Did you add an entry in /etc/syslog.conf for your daemon? If not check the man page for syslog.conf(5) for details ... -Zhihui #:^) -- So ya want ta here da roots? Dem that feels it knows it ... bush doctor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mounting a partition more than once
Matthew Dillon [EMAIL PROTECTED] wrote: :Tony Finch [EMAIL PROTECTED] wrote: : :Well, in the absence of any comments I hacked around a bit and ended :up with the following patch (against 3.3-RC), which permits the same :block device to be mounted read-only more than once. The motivation :for this is to permit multiple chrooted environments to share the same :/usr partition. Hmm... well, there is a problem here. I believe this will allow you to open the underlying block device read-only as well as mount the filesystem read-only. This will confuse the buffer cache badly. I don't think so -- spec_open checks whether the block device has been mounted in order to prevent this, and I made sure that that check remains in force except when spec_open is called by ffs_mountfs (by adding the FMOUNTING flag). I assumed that the buffer cache will handle multiple read-only mounts because it handles multiple userland reading file descriptors. Also, this may not be the best place to put the code. It make sense to be able to mount a block device multiple times in a read-only fashion, but the code should be in the open for the block device rather then in UFS/FFS, so it can be used with other filesystems and for other purposes. Yes, it's evident that this is true because I had to hack around essentially the same test in both spec_open and ffs_mountfs; removing the checks down from ffs_mountfs so it relies on spec_mount to DTRT would be neater, I think. Tony. -- f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED]e pluribus unix To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Dell PERC LVD card (Power Edge Raid Controller)
Thomas Uhrfelt wrote: An excellent initiative! I think there are many administrators/system managers out there with a huge stack of unused goods lying on the shelves to no use at all. Perhaps there should be a database where interested devicedriver programmers could post their needs and sysadminds could post their unneeded hardware on. Perhaps in that way we could speed up the development of HW drivers for FreeBSD? Any thoughts on this one? Kelly Yancey wrote: This is indeed a good idea. If nobody else has stepped up to the challenge, I will try to have such a site up by the end of the week (Well, let's make it Sunday...gives me the weekend to work on it too :) ). I'll keep everyone posted. Kelly I have gotten a few e-mail today pointing out that I didn't post anything about my progress on this web site on Sunday (like I promised above). I'm not dead, just a little delayed. :) Anyway, I'm making pretty good headway on the site and should have it wrapped up over the next couple of days. When I'm done, I'll let everyone know so maybe we can start geting more hardware into developers' hands! Kelly ~[EMAIL PROTECTED]~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
debugging a proc's kernel stack...
Hi, I want to see where some a deadlock is occurring in the kernel. I've got a dump with a bunch of processes in the inode or namecache state. Can anybody give me a hint about how to find a proc's "kernel stack" - so that I can find out what these kernel was doing for these processes when it locked up... (see "repeated deadlocks in FS ..." on the smp list for more info about the problem)... thanks alot, greg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations (followup)
!I think that what needs to be done is to split the problem in two. First, !allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT !is used, it simply means 'try harder, sleeping a bit if necessary'. This !requires ensuring that all the networking code deal with the failure !case - a time consuming but straightforward task. If a failure occurs, !one simply drops the packet, not the connection or anything else drastic. !just the packet. Yes, these is mainly the part I've been working on recently. The sleeping and what not (as I'm sure you've seen from the patches if you looked at them) has already been completed. Adding a counter that will expire and return a pre-defined error is trivial, in this case. The only real issue here (if we can call it that) is get _all_ the networking code to recognize this. Anyone want to help? :-) ! !The second problem that needs to be addressed is resource exhaustion. !For example, allocating thousands of connections and socket-opting their !buffers as large as possible, or programs such as syslog accepting new !connections ad-infinitum. This is a harder problem to fix properly, !but a lot of the various issues such as those with syslog can be dealt !with in userland rather then the kernel. ! ! -Matt ! I agree. The issue here is somewhat related (if I understand your explanation correctly) to [local] processes attempting to grab a lot of socket buffer space. I was a little less concerned with this issue since, as I previously mentionned, Brian Feldman is working on limiting socket buffer space. Nonetheless, if we do not consider limiting, here's what I believe will need to be done: As explained above, when we run out of mbufs and/or mbuf clusters (and some are needed), if we are M_WAIT (when processes socket opt their buffers as large as possible, the call is usually with M_WAIT), we will end up tsleep()ing for certain periods of time, until our counter expires and we return our pre-defined error (as mentionned above). When we do return this error, however, the caller (for instance, we can consider sosend() the caller -- which, if I remember correctly, is one of the callers to MGET() when we setsockopt a large buffer and consequently write() to this socket), will also have to know how to properly deal with this error (e.g.: kill the process?). Killing the process may seem somewhat sadistic to some ( :-) ), but remember that if we do get to the point where 'normal' local processes eat up so much buffer space that we run out, we should probably be increasing NMBCLUSTERS and/or maxusers anyway. As for script weenies, I hope that Brian (and whomever else may be working on it) gets that sockbuf limiting code done, because, to be quite honest, I don't think that script kids having to comprimise more than one account just so they can DoS a box will be much of an issue (if worse comes to worse, we can limit per gid -as opposed to per uid). With exhaustion attacks such as these, we're better off just limiting. Regards, Bosko Milekic. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mbuf shortage situations (followup)
On Mon, 13 Sep 1999, Garrett Wollman wrote: !On Sun, 12 Sep 1999 23:19:13 -0400 (EDT), Bosko Milekic [EMAIL PROTECTED] said: ! ! This message is in MIME format. The first part should be readable text, ! while the remaining parts are likely unreadable without MIME-aware tools. ! Send mail to [EMAIL PROTECTED] for more info. ! !It would be preferable if text were sent as text, since MIME-encoded !patches require more effort to read. ! I deffinately agree. This is obviously my mistake, and I was somewhat in a rush, very lagged (modem, eurgh), using pine, and made several [dumb] typos in the 'Attatchement' field. ! I'm also aware of the possiblity of some people not liking the ! fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). ! ! !I don't have any problem with sleeping forever -- but I am concerned !about the possibility of deadlock, especially when client-NFS is !involved. If the problem just moves around and has harder-to-recover !symptoms, the change isn't helping. Well, the main purpose of the code is to basically sleep until something is freed after we've already exhausted the mb_map arena (as I'm sure you've seen if you were able to grab the attachements). This is really a-la-limite stuff. In other words, if 'normal' local programs are having trouble because of mb_map exhaustion, then maxusers nmbclusters would have to be augmented. ! !The 4.3BSD code had two different behaviors: ! ! - For clusters, if M_WAIT was specified and there was no space !left in mb_map, it panicked. However, m_clalloc was never called with !M_WAIT, so that panic was effectively dead code. Hmmm. If m_clalloc was never called with M_WAIT, then all the code calling m_clalloc deffinately checked its return value. It probably had specific ways to deal with m_clalloc returning failures, too? ! ! - For mbufs, if M_WAIT was specified and there were no mbufs !available, it would sleep at PZERO - 1 (which was interruptible). ! !In 4.3, the code was able to deal with cluster allocation failing. We !have a somewhat different situation now, because many network !interface devices have less-flexible DMA mechanisms which don't allow !packet reception into non-contiguous buffers, so we need to have at !least a certain number of clusters available for this purpose. Exactly. This is the next challenge. As for things being interruptable, as I mentionned to a reply to Matt Dillon just a few seconds ago, getting the tsleep to occasionally expire is trivial. As you say above, it's dealing with the failure that is the issue. ! !-GAWollman ! !-- !Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same ![EMAIL PROTECTED] | O Siem / The fires of freedom !Opinions not those of| Dance in the burning flame !MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick ! Cheers, Bosko Milekic. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: A Challenge
* Nate Williams (n...@mt.sri.com) [990910 07:14]: In any case, if you install a recent version of FreeBSD, I doubt Mr. NT is capable of crashing FreeBSD from externally. Just make sure he doesn't have an account on it, since it's much easier to cause Denial Of Service attacks if you don't spend alot of time setting up limits and such. Going even further than what Nate said, remove all accounts you don't need. Give only accounts to those who need to admin the box, other than that DO NOT give away accounts. Make sure the security log files sent by email are being sent to the correct persons. Remove /usr/src and compile kernels on a secondary host so you are sure that compiling stuff on the firewall is hard after a compromise. Use ssh and ditch telnet. read security(9) -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best If Winter comes, can Spring be far behind? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: submiting source code ?
* Gustavo V G C Rios (gr...@ddsecurity.com.br) [990910 04:14]: I use freebsd about +- 12 months ago. I have never did any thing serious at kernel level, nor i know anything about kernel desgin. Start with: Modern Operating Systems by Andrew S. Tanenbaum The Design and Implementation of 4.4BSD by Marshall Kirk McKusick et al. Unix Internals: The New Frontiers Then you probably need more special in-depth books such as: TCP/IP Illustrated by (R.I.P.) W. Richard Stevens Unix Network Programming by W. Richard Stevens The Unix Programming Environment by Rob Pike and Ritchie Kerninghan Advanced Programming in the Unix Environment by W. Richard Stevens Suppose, i would like to spend time and patience learnig Fbsd internals. If, later, i were able to code something to freebsd, and suppose i do, what (or better, how) should i do to have my source accepted by the core team? send-pr after you have tested, style(9)'d, documented your code and tested you patches against a clean checked out source base. What about coding style ? As Chris said, style(9) What are the golden rules to have my sources widely accepted by freebsd community? Don't go the Linux way which tends to favor bloat over solid code. Portability and correctness of code is more important than features. PS: This is my first attempt to start touching the kernel, so, don't blame, if i wrote something wrong. That's ok, it's a long way before you actually will start touching the sources though, it involves a lot of RTFM'ing and UTSL'ing first. -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Workers of the world, unite! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NetWare client in -current
On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote: Growing up programming on a KL-10, I still think the correct place for line-editing is in the driver. Hell - it's already doing basic erase/kill line editing as it is. Then you don't have to hack every command-line app to get line-editing. Yeah, but how do you specify completion then? Unix went here a long time ago and backed out of it. Have a look at the paper http://www.cs.princeton.edu/~jlk/kornshell/doc/vhll.ps.gz (linked from www.kornshell.com) in particular, the history section. -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator vi has two modes the one in which it beeps and the one in which it doesnt. -- Anon. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: How to prevent motd including os info
Rodney W. Grimes free...@gndrsh.dnsmgr.net writes: No. The scrollback may be too short (especially after an fsck of a large filesystem after a crash), and it may even be empty (if you put something like VESA_132x60 in allscreens_flags in rc.conf) We can tune the size of the scroll back buffer can't we? Yes, but we don't want to increase the default size too much. And fsck output even after a crash is usually not that long, if it gets long it usually has more problems than fsck -p can deal with and stops any way. You've obviously never fsck'ed a largish soft-updated filesystem after a power outage. Why does switching display mode screw up the scroll back buffer? That sounds broken to me. Because you have to resize the scrollback to accomodate the new line width. You're welcome to fix it. I've tried, and decided that it was far from a SMOP and that it would have to wait until I have more than a few hours' continuous free time. Doesn't ntpdate log what it does with syslog? If you give it the -s option, yes it will syslog it. But doing that to everything in /etc/rc* seems like a pain in the *ss... Lazy people never achieve much. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
de0 strangenesses
On a 3.0-current of October 1998 I'm having often trouble with de0. The machine often reboots over night (when either the locate db is built or some other big job - like mirror - is running). Anyway, after the reboot, often de0 is dead. This happend today again. When I came into the office I could not ping said machine. I sat at the console, logged in. The machine was perfectly alive, only the de0 interface didn't work at the BNC network. I did a ifconfig de0 down and exactly with doing that I got a kernel message from the driver: de0 BNC interface enabled (or something like that). Doing an ifconfig de0 up right after that the interface continued working at the BNC port. Can the driver writer(s) comment whether there have been changes to the driver WRT that behaviour so I can expect that with either 3.2 or -current the problem would be gone? -- Chris Christoph P. U. Kukulies k...@gil.physik.rwth-aachen.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: More press
Dirk GOUDERS h...@musashi.et.bocholt.fh-ge.de writes: Oh, sorry -- my browse-url-at-mouse function made http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242 c00.html of it... Netscape uses commans to separate parameters to the OpenURL command. Fortunately, the API is open and documented, so there's nothing to stop someone from writing a small command-line util that does the equivalent of netscape -remote except faster and better. Well, having read all of your remarks, I noticed, that emacs' lisp code browse-url.el causes the generation of http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242 c00.html instead of http://www.zdnet.com/zdtv/screensavers/answerstips/story/0%2c3656%2c2324624%2 c00.html I fixed that (little) problem on my machine and sent a bug-report. Now, I enjoy loading URLs containing commas :-) Dirk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: More press
On Sun, Sep 12, 1999 at 03:22:55PM +0200, Dag-Erling Smorgrav wrote: Dirk GOUDERS h...@musashi.et.bocholt.fh-ge.de writes: Oh, sorry -- my browse-url-at-mouse function made http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242c00.html of it... Netscape uses commans to separate parameters to the OpenURL command. Fortunately, the API is open and documented, so there's nothing to stop someone from writing a small command-line util that does the equivalent of netscape -remote except faster and better. If you follow the link from netscape -help, you end up at: http://home.netscape.com/newsref/std/remote.c Which is a small C program to do just that. I really should turn it into a port... -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator vi has two modes the one in which it beeps and the one in which it doesnt. -- Anon. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: More press
Dominic Mitchell dom.mitch...@palmerharvey.co.uk writes: If you follow the link from netscape -help, you end up at: http://home.netscape.com/newsref/std/remote.c The page you attempted to access was not found on Netscape's web site. You may have typed its location incorrectly, or it may have been moved, deleted, or incorporated into another part of Netscape's site. To report a broken link, please send a message to feedback. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Problem with FreeBSD
Hello All. I try install FreeBSD on HP Vectra VA/200DT - Pentium Pro/128Mb-RAM/ Quantum Fireball CR 4.3Gb/CirrusLogic5446PCI PCI/NE2000. When I try install FreeBSD (I'm tried 3.2-release/3.3-19990909-rc/snapshot-4.0-19990827-current) i have some trouble. On second floppy (mfsroot.flp) before kernel setup, FreeBSD write zf_read: error. After this, I configured kernel (i kept only fdc0, wdc0, atkbd0, sc0) and when system wrote changing root device to fd0c and after this rootfs is 2880Kbyte compiled in MFS system stilled and doesn't run install proces, but Pause key and scrolling was working. Best regards, Zherdev Anatoly tol...@ru.ru To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
[no subject]
To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: More press
On Mon, Sep 13, 1999 at 11:45:50AM +0200, Dag-Erling Smorgrav wrote: Dominic Mitchell dom.mitch...@palmerharvey.co.uk writes: If you follow the link from netscape -help, you end up at: http://home.netscape.com/newsref/std/remote.c The page you attempted to access was not found on Netscape's web site. You may have typed its location incorrectly, or it may have been moved, deleted, or incorporated into another part of Netscape's site. To report a broken link, please send a message to feedback. It works from here. Yell if you want me to mail it to you. micha...@singsing:~$ wget http://home.netscape.com/newsref/std/remote.c --11:41:07-- http://home.netscape.com:80/newsref/std/remote.c = `remote.c' Connecting to home.netscape.com:80... connected! HTTP request sent, awaiting response... 200 OK Length: 18,579 [text/plain] 0K - .. [100%] 11:41:08 (29.55 KB/s) - `remote.c' saved [18579/18579] micha...@singsing:~$ head -3 remote.c /* -*- Mode:C; tab-width: 8 -*- * remote.c --- remote control of Netscape Navigator for Unix. * version 1.1.3, for Netscape Navigator 1.1 and newer. micha...@singsing:~$ -- Mike Bristow, Geek At Large GK/RM0501 Nobody's ugly after 2AM To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: How to prevent motd including os info
Rodney W. Grimes wrote: It dawned on me what can be done. Look, we get all the kernel printf's from the dmesg output saved in a buffer and pull that out later with syslog, looks like we could just slip a pipe fitting into /dev/console that copies all it's output into the mesgbuf as well, until we smack it wth the ballpean and tell it to stop doing that (Either getty lanching the login: on ttyv0 could cause this, or something at the end of /etc/rc). What do you think of that idea? I think that's a fine idea, and it's a lot cleaner than mine for a number of reasons. Completely beyond me to code, but very nice from the design standpoint. Most of the time I could care less what /etc/rc spits out. However, in the past, I have had to go add sleep(###) calls in various spots in rc to that I could actually read some of the error output to figure out why something was failing. I wouldn't mind having all of the /etc/rc output sent to the message buffer (and /dev/console) until a getty is running on ttyv0. Or at least make it a boot option. If you are having problems, boot the kernel with boot -l in the boot loader. Now, adding an option doesn't help in the case of fsck suddenly generating a million lines of output during boot, since that might not be expected, but it does help some cases. And scrollback buffers and message buffers only help if you have enough memory to hold all of that information. Right now I have 3 FreeBSD machine. 1 has 192MB of RAM. I have the message buffer set to some very large value (because of some boot problem I bumped it up a lot), so I at least see all of the kernel messages that were generating during a boot. This helped me debug a couple of problems. The other two machines only have 16MB, so they still run with a standard message buffer (geez, I remember when 16MB was *A LOT*). Perhaps we need a boot message buffer (just eat up free memory minus some protected space that is reserved for letting /etc/rc run without swapping). Keep sending data to that buffer during the boot process, and just before going multi-user, dump it off to disk and free it. On a 16MB machine, that shouldn't be a problem. For those people still running FreeBSD machines on 4MB, that is another story, but even in those cases, I would bet you could still be able to record and store at least some of the /etc/rc output. Its been a few years since I've seen fsck generate a couple of megabytes of output, so I know it is possible, but I think this idea could work, and solve most peoples problem of fsck generating MANY pages of output that just scroll by. -Mike -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: How to prevent motd including os info
[I'm catching up on a bunch of FreeBSD mail since being out on vacation, so perhaps I've missed the essence of this thread..] I've also had the desire to capture the output produced when /etc/rc is run for all the reasons mentioned. I always thought that perhaps init would simply capture stdout on the other end of a pipe, and logically do the tee thing with it. In fact, couldn't init logically exec a sh /etc/rc | tee /tmp/rc-output when invoking /etc/rc? (Where to put the output would seem to be one of the more difficult choices since you don't start with a writable file system mounted anywhere..) Or perhaps init could capture the output on the end of a pipe and subsequently syslog it while it's echoing it to /dev/console. louie To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
L440GX+ Server Board
Hi list, I can't solve the problem yet. When I runnig the dmesg command, I have: --- da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST39140LW 1483 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST39140LW 1483 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) --- I did a test, changing only the SCSI disk, using the same motherboard (L440GX+). I ran the dmesg command again and I received: -- da0 at ahc0 bus 0 target 0 lun 0 da0: QUANTUM QM39100TD-SW N491 Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8683MB (17783250 512 byte sectors: 255H 63S/T 1106C) -- I realized that the quantum disk have a 80.000MB/s transfers. Does someone use a SEAGATE ST39140LW disk and have I/O problems? Regards, Luiz Morte. PS: Someone told me that vipw doens't have much I/O disk, but when I run it with 12000 accounts, my disk have a lot off access. On Sun, 22 Aug 1999, Luiz Morte da Costa Junior wrote: Hi all, I have a problem with a server running a FreeBSD 3.2. My Server has a L440GX+ Serber Board (intel), with network card 10/100, SCSI AIC 7896 (80MB/s), 2 SCSI disk with 9GB (80MB/s), 2 pentium III 450Mhz (not overclocked). The NIC and SCSI are onboard. I recompiled a kernel to SMP, and it worked. The server is ok, but when I run a comand with disk access (whith vipw or mysql), the performance of server goes down. My server stays very very very slow. If I use pine to read my messages, it doesn't work. When the comand finishes, the server stays ok again. I recompiled the kernel with maxusers 128, but it doesn't work. My SCSI cable has a terminator and the scsi setup is ok (I think :) ). The dmesg command output is in attchmnt. I appreciate any help. []s, Luiz Morte da Costa Junior Analista de RedesE-mail: mo...@correionet.com.br Telefone: +55 19 754-2532Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: de0 strangenesses
Christoph Kukulies writes: On a 3.0-current of October 1998 I'm having often trouble with de0. The machine often reboots over night (when either the locate db is built or some other big job - like mirror - is running). Anyway, after the reboot, often de0 is dead. This happend today again. When I came into the office I could not ping said machine. I sat at the console, logged in. The machine was perfectly alive, only the de0 interface didn't work at the BNC network. I did a ifconfig de0 down and exactly with doing that I got a kernel message from the driver: de0 BNC interface enabled (or something like that). Doing an ifconfig de0 up right after that the interface continued working at the BNC port. Can the driver writer(s) comment whether there have been changes to the driver WRT that behaviour so I can expect that with either 3.2 or -current the problem would be gone? this is old problem - I have it in 2.2.7-RELEASE too -- Chris Christoph P. U. Kukulies k...@gil.physik.rwth-aachen.de -- @BABOLO http://links.ru/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: L440GX+ Server Board
|o|... Mon, Sep 13, 1999 at 10:16:30AM -0300, Luiz Morte da Costa Junior ...|o| wrote: Hi list, I can't solve the problem yet. When I runnig the dmesg command, I have: --- da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST39140LW 1483 Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da0: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) da1 at ahc0 bus 0 target 1 lun 0 da1: SEAGATE ST39140LW 1483 Fixed Direct Access SCSI-2 device da1: 40.000MB/s transfers (20.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 8683MB (17783240 512 byte sectors: 255H 63S/T 1106C) --- I did a test, changing only the SCSI disk, using the same motherboard (L440GX+). I ran the dmesg command again and I received: -- da0 at ahc0 bus 0 target 0 lun 0 da0: QUANTUM QM39100TD-SW N491 Fixed Direct Access SCSI-2 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8683MB (17783250 512 byte sectors: 255H 63S/T 1106C) -- I realized that the quantum disk have a 80.000MB/s transfers. Does someone use a SEAGATE ST39140LW disk and have I/O problems? Regards, Luiz Morte. PS: Someone told me that vipw doens't have much I/O disk, but when I run it with 12000 accounts, my disk have a lot off access. da uma olhada se ele nao ta paginando, a geracao do dbm novo e' rapida se vc disser para ele fazer tudo em ram, senao ele faz em disco O pwd_mkdb tem esta opcao para evitar isso: -s cachesize Specify in megabytes the size of the memory cache used by the hash- ing library. On systems with a large user base, a small cache size can lead to prohibitively long database file rebuild times. As a rough guide, the memory usage of pwd_mkdb in megabytes will be a little bit more than twice the figure specified here. The default is 2 megabytes. poe ai 16M e testa pra ver, o vipw que chama ele nao tem, vc pode recompilar o pwd_mkdb c/ um default de 16M se for o caso On Sun, 22 Aug 1999, Luiz Morte da Costa Junior wrote: Hi all, I have a problem with a server running a FreeBSD 3.2. My Server has a L440GX+ Serber Board (intel), with network card 10/100, SCSI AIC 7896 (80MB/s), 2 SCSI disk with 9GB (80MB/s), 2 pentium III 450Mhz (not overclocked). The NIC and SCSI are onboard. I recompiled a kernel to SMP, and it worked. The server is ok, but when I run a comand with disk access (whith vipw or mysql), the performance of server goes down. My server stays very very very slow. If I use pine to read my messages, it doesn't work. When the comand finishes, the server stays ok again. I recompiled the kernel with maxusers 128, but it doesn't work. My SCSI cable has a terminator and the scsi setup is ok (I think :) ). The dmesg command output is in attchmnt. I appreciate any help. []s, Luiz Morte da Costa Junior Analista de RedesE-mail: mo...@correionet.com.br Telefone: +55 19 754-2532Fax: +55 19 255-7576 CorreioNet - Correio Popular Campinas - SP - Brazil To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- .sig: license expired, contact your vendor To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: More Press
Date: Mon, 13 Sep 1999 10:31:51 +0100 From: Dominic Mitchell dom.mitch...@palmerharvey.co.uk Subject: Re: More press On Sun, Sep 12, 1999 at 03:22:55PM +0200, Dag-Erling Smorgrav wrote: Dirk GOUDERS h...@musashi.et.bocholt.fh-ge.de writes: Oh, sorry -- my browse-url-at-mouse function made http://www.zdnet.com/zdtv/screensavers/answerstips/story/02c36562c23246242c0 0.html of it... Netscape uses commans to separate parameters to the OpenURL command. Fortunately, the API is open and documented, so there's nothing to stop someone from writing a small command-line util that does the equivalent of netscape -remote except faster and better. If you follow the link from netscape -help, you end up at: http://home.netscape.com/newsref/std/remote.c Which is a small C program to do just that. I really should turn it into a port... If you haven't already, I've just about finished a port for this (it is pretty nifty). The only problem I have currently is that I have to fetch 2 files for the port (the file listed above, as well as http://home.netscape.com/newsref/std/vroot.h). Without making a separate port just for vroot.h, if there a way to have the port fetch 2 files? Should I just list it using PATCH_SITES/PATCHFILES even though it isn't really a patch? Other than that I have to write a few patches of my own (the netscape source segfaults if no command is given and apparently presumes netscape 1.1). If I can find out the answer to fetching the 2 files, I'll send-pr the port right away. Thanks, Kelly ~kby...@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: submiting source code ?
Hay, thaaank you! I really glad to receive your message! It will really shelp. Again, thanks a lot! Jeroen Ruigrok/Asmodai wrote: * Gustavo V G C Rios (gr...@ddsecurity.com.br) [990910 04:14]: I use freebsd about +- 12 months ago. I have never did any thing serious at kernel level, nor i know anything about kernel desgin. Start with: Modern Operating Systems by Andrew S. Tanenbaum The Design and Implementation of 4.4BSD by Marshall Kirk McKusick et al. Unix Internals: The New Frontiers Then you probably need more special in-depth books such as: TCP/IP Illustrated by (R.I.P.) W. Richard Stevens Unix Network Programming by W. Richard Stevens The Unix Programming Environment by Rob Pike and Ritchie Kerninghan Advanced Programming in the Unix Environment by W. Richard Stevens Suppose, i would like to spend time and patience learnig Fbsd internals. If, later, i were able to code something to freebsd, and suppose i do, what (or better, how) should i do to have my source accepted by the core team? send-pr after you have tested, style(9)'d, documented your code and tested you patches against a clean checked out source base. What about coding style ? As Chris said, style(9) What are the golden rules to have my sources widely accepted by freebsd community? Don't go the Linux way which tends to favor bloat over solid code. Portability and correctness of code is more important than features. PS: This is my first attempt to start touching the kernel, so, don't blame, if i wrote something wrong. That's ok, it's a long way before you actually will start touching the sources though, it involves a lot of RTFM'ing and UTSL'ing first. -- Jeroen Ruigrok van der Werven/Asmodai asmodai(at)wxs.nl The BSD Programmer's Documentation Project http://home.wxs.nl/~asmodai Network/Security SpecialistBSD: Technical excellence at its best Workers of the world, unite! To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: More Press
On Mon, Sep 13, 1999 at 10:48:07AM -0400, Kelly Yancey wrote: If you haven't already, I've just about finished a port for this (it is pretty nifty). The only problem I have currently is that I have to fetch 2 files for the port (the file listed above, as well as http://home.netscape.com/newsref/std/vroot.h). Without making a separate port just for vroot.h, if there a way to have the port fetch 2 files? Should I just list it using PATCH_SITES/PATCHFILES even though it isn't really a patch? Other than that I have to write a few patches of my own (the netscape source segfaults if no command is given and apparently presumes netscape 1.1). If I can find out the answer to fetching the 2 files, I'll send-pr the port right away. Take a look at the XFree86 port in x11. That fetches two large tarballs, and therefore probably does the right thing. Joe -- Josef KarthauserFreeBSD: How many times have you booted today? Technical Manager Viagra for your server (http://www.uk.freebsd.org) Pavilion Internet plc. [...@pavilion.net, j...@uk.freebsd.org, j...@tao.org.uk] To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: More press
On 13-Sep-99 Mike Bristow wrote: On Mon, Sep 13, 1999 at 11:45:50AM +0200, Dag-Erling Smorgrav wrote: Dominic Mitchell dom.mitch...@palmerharvey.co.uk writes: If you follow the link from netscape -help, you end up at: http://home.netscape.com/newsref/std/remote.c The page you attempted to access was not found on Netscape's web site. You may have typed its location incorrectly, or it may have been moved, deleted, or incorporated into another part of Netscape's site. To report a broken link, please send a message to feedback. It works from here. Yell if you want me to mail it to you. You probably already have it, as /usr/src/contrib/global/gozilla/remote.c -- Duane H. Hesser d...@androcles.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: More Press
-Original Message- From: Josef Karthauser [mailto:j...@pavilion.net] Sent: Monday, September 13, 1999 10:57 AM To: Kelly Yancey Cc: hack...@freebsd.org; dom.mitch...@palmerharvey.co.uk Subject: Re: More Press On Mon, Sep 13, 1999 at 10:48:07AM -0400, Kelly Yancey wrote: If you haven't already, I've just about finished a port for this (it is pretty nifty). The only problem I have currently is that I have to fetch 2 files for the port (the file listed above, as well as http://home.netscape.com/newsref/std/vroot.h). Without making a separate port just for vroot.h, if there a way to have the port fetch 2 files? Should I just list it using PATCH_SITES/PATCHFILES even though it isn't really a patch? Other than that I have to write a few patches of my own (the netscape source segfaults if no command is given and apparently presumes netscape 1.1). If I can find out the answer to fetching the 2 files, I'll send-pr the port right away. Take a look at the XFree86 port in x11. That fetches two large tarballs, and therefore probably does the right thing. Bingo...that did the trick, port coming soon... Kelly ~kby...@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: More press
On Mon, Sep 13, 1999 at 07:59:03AM -0700, Duane H. Hesser wrote: You probably already have it, as /usr/src/contrib/global/gozilla/remote.c Blimey! -- Dom Mitchell -- Palmer Harvey McLane -- Unix Systems Administrator vi has two modes the one in which it beeps and the one in which it doesnt. -- Anon. ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ** To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
device driver interface
I am trying to understand how to integrate device drivers with the kernel. (this is my first crack at device drivers) I have a few books on device drivers but they are a little old and have a slightly different interface with the kernel than FreeBSD. I figured the best place to start would be to try to building one of the samples. So did I did /usr/share/examples/drivers/make_device_drivers.sh WDC. The script will attempt to build the kernel and I get the following errors: cc -c -O -Wreturn-type -Wcomment -Wredundant-decls -Wimplicit -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wuninitialized -Wformat -Wunused -fformat-extensions -ansi -nostdinc -I- -I. -I../.. -I/usr/include -DKERNEL -DVM_STACK -include opt_global.h -elf ../../i386/isa/WCD.c ../../i386/isa/WCD.c: In function `WCDattach': ../../i386/isa/WCD.c:137: `WCDintr' undeclared (first use this function) ../../i386/isa/WCD.c:137: (Each undeclared identifier is reported only once ../../i386/isa/WCD.c:137: for each function it appears in.) ../../i386/isa/WCD.c: At top level: ../../i386/isa/WCD.c:177: `WCDintr' used prior to declaration ../../i386/isa/WCD.c: In function `WCDintr': ../../i386/isa/WCD.c:178: warning: unused variable `scp' ../../i386/isa/WCD.c: At top level: ../../i386/isa/WCD.c:188: conflicting types for `WCDioctl' ../../i386/isa/WCD.c:30: previous declaration of `WCDioctl' ../../i386/isa/WCD.c: In function `WCDclose': ../../i386/isa/WCD.c:226: warning: unused variable `scp' ../../i386/isa/WCD.c: In function `WCDread': ../../i386/isa/WCD.c:250: dereferencing pointer to incomplete type ../../sys/libkern.h:57: warning: inlining failed in call to `min' ../../i386/isa/WCD.c:250: warning: called from here ../../i386/isa/WCD.c:251: warning: implicit declaration of function `uiomove' ../../i386/isa/WCD.c: In function `WCDwrite': ../../i386/isa/WCD.c:267: dereferencing pointer to incomplete type ../../i386/isa/WCD.c: At top level: ../../i386/isa/WCD.c:273: conflicting types for `WCDmmap' ../../i386/isa/WCD.c:31: previous declaration of `WCDmmap' ../../i386/isa/WCD.c: In function `WCDmmap': ../../i386/isa/WCD.c:275: warning: unused variable `scp' ../../i386/isa/WCD.c: In function `WCDpoll': ../../i386/isa/WCD.c:296: warning: unused variable `scp' ../../i386/isa/WCD.c: At top level: ../../i386/isa/WCD.c:177: warning: `WCDintr' defined but not used *** Error code 1 Why does this fail? This script was installed of off my 3.2 cd set. Does anyone know of an existing driver that would be a good place to start for a newbie to understand these things? Any and all help is appreciated, Wayne To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: More Press
On Mon, Sep 13, 1999 at 10:48:07AM -0400, Kelly Yancey wrote: If you haven't already, I've just about finished a port for this (it is pretty nifty). The only problem I have currently is that I have to fetch 2 files for the port (the file listed above, as well as http://home.netscape.com/newsref/std/vroot.h). Without making a separate port just for vroot.h, if there a way to have the port fetch 2 files? Should I just list it using PATCH_SITES/PATCHFILES even though it isn't really a patch? Other than that I have to write a few patches of my own (the netscape source segfaults if no command is given and apparently presumes netscape 1.1). If I can find out the answer to fetching the 2 files, I'll send-pr the port right away. (Yep, quoting myself :) ) Alright, anyone who wants to give it a whirl, the port has been submitted as ports/13727. It works well, but I must say it required a little bit of effort to escape the netscape-remote commands from the command-line. Kelly ~kby...@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NetWare client in -current
On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote: Growing up programming on a KL-10, I still think the correct place for line-editing is in the driver. Hell - it's already doing basic erase/kill line editing as it is. Then you don't have to hack every command-line app to get line-editing. Yeah, and this is why VMS 4.X (early) had a terrific security bug- if you type '#' (or was it '') as the first character after you logged in, your accounting records for that session were wiped. No, a driver is *not* the place to put this kind of fooling around. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mounting a partition more than once
Tony Finch f...@demon.net wrote:
Is there a reason for disallowing concurrent read-only mounts of the
same disk device? i.e. would things go pear-shaped if I added this
capability?
Well, in the absence of any comments I hacked around a bit and ended
up with the following patch (against 3.3-RC), which permits the same
block device to be mounted read-only more than once. The motivation
for this is to permit multiple chrooted environments to share the same
/usr partition.
Some things I wonder about this change is whether the mounts will share
the same pages in the buffer cache, and whether the resource
accounting is still right. I've subtly funted the meaning of
v_specmountpoint when multiple mounts happen; does this matter?
Tony.
--
f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix
--- /usr/src/sys/sys/fcntl.h.orig Mon Sep 13 15:21:29 1999
+++ /usr/src/sys/sys/fcntl.hMon Sep 13 17:04:46 1999
@@ -93,6 +93,7 @@
#defineFMARK 0x1000 /* mark during gc() */
#defineFDEFER 0x2000 /* defer for next gc pass */
#defineFHASLOCK0x4000 /* descriptor holds advisory
lock */
+#defineFMOUNTING 0x8000 /* a block device is being
mounted */
#endif
/* Defined by POSIX 1003.1; BSD default, but must be distinct from O_RDONLY. */
--- /usr/src/sys/miscfs/specfs/spec_vnops.c.origMon Sep 13 17:11:17 1999
+++ /usr/src/sys/miscfs/specfs/spec_vnops.c Mon Sep 13 15:37:22 1999
@@ -229,7 +229,7 @@
* Do not allow opens of block devices that are
* currently mounted.
*/
- error = vfs_mountedon(vp);
+ error = (ap-a_mode FMOUNTING) ? 0 : vfs_mountedon(vp);
if (error)
return (error);
return ((*bdevsw[maj]-d_open)(dev, ap-a_mode, S_IFBLK, p));
--- /usr/src/sys/kern/vfs_subr.c.orig Mon Sep 13 11:44:59 1999
+++ /usr/src/sys/kern/vfs_subr.cMon Sep 13 11:55:06 1999
@@ -1886,6 +1886,39 @@
simple_unlock(spechash_slock);
return (count);
}
+
+/*
+ * Calculate the total number of writers on a special device.
+ */
+int
+vwritecount(vp)
+ register struct vnode *vp;
+{
+ struct vnode *vq, *vnext;
+ int count;
+
+loop:
+ if ((vp-v_flag VALIASED) == 0)
+ return (vp-v_writecount);
+ simple_lock(spechash_slock);
+ for (count = 0, vq = *vp-v_hashchain; vq; vq = vnext) {
+ vnext = vq-v_specnext;
+ if (vq-v_rdev != vp-v_rdev || vq-v_type != vp-v_type)
+ continue;
+ /*
+* Alias, but not in use, so flush it out.
+*/
+ if (vq-v_writecount == 0 vq != vp) {
+ simple_unlock(spechash_slock);
+ vgone(vq);
+ goto loop;
+ }
+ count += vq-v_writecount;
+ }
+ simple_unlock(spechash_slock);
+ return (count);
+}
+
/*
* Print out a description of a vnode.
*/
--- /usr/src/sys/ufs/ffs/ffs_vfsops.c.orig Mon Sep 13 11:21:07 1999
+++ /usr/src/sys/ufs/ffs/ffs_vfsops.c Mon Sep 13 17:08:23 1999
@@ -586,28 +586,33 @@
struct ucred *cred;
u_int64_t maxfilesize; /* XXX */
size_t strsize;
- int ncount;
+ int ncount, nwritecount;
dev = devvp-v_rdev;
cred = p ? p-p_ucred : NOCRED;
+ ronly = (mp-mnt_flag MNT_RDONLY) != 0;
/*
-* Disallow multiple mounts of the same device.
+* Only allow multiple read-only mounts of the same device.
* Disallow mounting of a device that is currently in use
* (except for root, which might share swap device for miniroot).
* Flush out any old buffers remaining from a previous use.
*/
- error = vfs_mountedon(devvp);
+ error = ronly ? 0 : vfs_mountedon(devvp);
if (error)
return (error);
+ nwritecount = vwritecount(devvp);
+ if (nwritecount)
+ return (EBUSY);
ncount = vcount(devvp);
-
- if (ncount 1 devvp != rootvp)
+ if (!ronly ncount 1 devvp != rootvp)
return (EBUSY);
- vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
- error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
- VOP_UNLOCK(devvp, 0, p);
- if (error)
- return (error);
+ if (ncount = 1) {
+ vn_lock(devvp, LK_EXCLUSIVE | LK_RETRY, p);
+ error = vinvalbuf(devvp, V_SAVE, cred, p, 0, 0);
+ VOP_UNLOCK(devvp, 0, p);
+ if (error)
+ return (error);
+ }
/*
* Only VMIO the backing device if the backing device is a real
@@ -622,8 +627,8 @@
VOP_UNLOCK(devvp, LK_INTERLOCK, p);
}
- ronly = (mp-mnt_flag
softupdates panic in 3.3-RC
Our ftp server crashed early this morning with what appears to be a softupdates error: Sep 13 09:56:19 stumble /kernel: pid 41477 (perl), uid 0 on /exports/share3/ftp/.2: file system full panic: softdep_write_inodeblock: indirect pointer #0 mismatch 0 != 15597568 syncing disks... panic: softdep_lock: locking against myself 'perl' would have been the nightly mirror(1) run to sync up our ftp site. What additional details would be usefull? We didn't have crashdumps enabled on this machine, so a backtrace is not fully possible, although it would seem the contextual evidence for what went wrong is strong. -- David Cross | email: cro...@cs.rpi.edu 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 majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Let a daemon process print a message
Can anyone tell me how to let a daemon process print a message to the console? Adding printf() does not work (I wonder if a daemon process has been cut of relationship with stdout). Thanks for any help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
subscribe
subscribe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Let a daemon process print a message
syslog() with the proper facility is probably the best way to do this. Another possibility is opening /dev/console, but I think that will aquire a controlling terminal. On Mon, 13 Sep 1999, Zhihui Zhang wrote: Can anyone tell me how to let a daemon process print a message to the console? Adding printf() does not work (I wonder if a daemon process has been cut of relationship with stdout). Thanks for any help. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: more info Re: how did I manage this?
On Sun, Sep 12, 1999 at 12:29:55PM -0400, Wayne Cuddy wrote: rm '$DEST_DIR' rm: $DEST_DIR: is a directory ls '$DEST_DIR' $2 rm doesn't work on directories.. go for $ rm -rf '$DEST_DIR' or $ rm '$DEST_DIR'/'$2' $ rmdir '$DEST_DIR' regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf shortage situations (followup)
On Sun, 12 Sep 1999 23:19:13 -0400 (EDT), Bosko Milekic bmile...@dsuper.net said: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. Send mail to m...@docserver.cac.washington.edu for more info. It would be preferable if text were sent as text, since MIME-encoded patches require more effort to read. I'm also aware of the possiblity of some people not liking the fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). I don't have any problem with sleeping forever -- but I am concerned about the possibility of deadlock, especially when client-NFS is involved. If the problem just moves around and has harder-to-recover symptoms, the change isn't helping. The 4.3BSD code had two different behaviors: - For clusters, if M_WAIT was specified and there was no space left in mb_map, it panicked. However, m_clalloc was never called with M_WAIT, so that panic was effectively dead code. - For mbufs, if M_WAIT was specified and there were no mbufs available, it would sleep at PZERO - 1 (which was interruptible). In 4.3, the code was able to deal with cluster allocation failing. We have a somewhat different situation now, because many network interface devices have less-flexible DMA mechanisms which don't allow packet reception into non-contiguous buffers, so we need to have at least a certain number of clusters available for this purpose. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: damn ATX power supplies...
Just my 2 cents and a staple ... A staple bent properly and wedged in the crimp part of the pin between the green wire to a black wire does the trick for me. Now I turn that machine on via the power switch on the back of the power supply which ATX power supply people are now adding. I have a devel motherboard that I'm using without a manual and without a working on button. For more info just look at the various ATX spec's online. Doug A. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: damn ATX power supplies...
On 13 Sep, Doug Ambrisko wrote: A staple bent properly and wedged in the crimp part of the pin between the green wire to a black wire does the trick for me. When building a box of disks (no m/b) we used a paper clip. No m/b meant we could just short the pins and not worry about plugging it in. Damm lab tech. saw it and did it properly (even used heat shrink on the patched wires, sigh... how tidy and h/w like is that). Oh, and watch our for the Canon ATX Motherboard Emulator patent ;) -- Andy Newman To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Let a daemon process print a message
On Mon, 13 Sep 1999, Brian Mitchell (ISSATL) wrote: syslog() with the proper facility is probably the best way to do this. Another possibility is opening /dev/console, but I think that will aquire a controlling terminal. On Mon, 13 Sep 1999, Zhihui Zhang wrote: Can anyone tell me how to let a daemon process print a message to the console? Adding printf() does not work (I wonder if a daemon process has been cut of relationship with stdout). Thanks for any help. I have tested syslog(). I find out: (1) The log messages will go into /var/log/messages and appear on the console only after I login in (as root). (2) The LOG_INFO priority does not cause the messages to appear on the console or to be written into file /var/log/messages. Can anyone explain the reason for me? Thanks a lot. -Zhihui To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Let a daemon process print a message
Out of da blue Zhihui Zhang aka (zzh...@cs.binghamton.edu) said: On Mon, 13 Sep 1999, Brian Mitchell (ISSATL) wrote: syslog() with the proper facility is probably the best way to do this. Another possibility is opening /dev/console, but I think that will aquire a controlling terminal. On Mon, 13 Sep 1999, Zhihui Zhang wrote: Can anyone tell me how to let a daemon process print a message to the console? Adding printf() does not work (I wonder if a daemon process has been cut of relationship with stdout). Thanks for any help. I have tested syslog(). I find out: (1) The log messages will go into /var/log/messages and appear on the console only after I login in (as root). (2) The LOG_INFO priority does not cause the messages to appear on the console or to be written into file /var/log/messages. Can anyone explain the reason for me? Thanks a lot. Did you add an entry in /etc/syslog.conf for your daemon? If not check the man page for syslog.conf(5) for details ... -Zhihui #:^) -- So ya want ta here da roots? Dem that feels it knows it ... bush doctor derv...@bantu.cl.msu.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mounting a partition more than once
Matthew Dillon dil...@apollo.backplane.com wrote: :Tony Finch f...@demon.net wrote: : :Well, in the absence of any comments I hacked around a bit and ended :up with the following patch (against 3.3-RC), which permits the same :block device to be mounted read-only more than once. The motivation :for this is to permit multiple chrooted environments to share the same :/usr partition. Hmm... well, there is a problem here. I believe this will allow you to open the underlying block device read-only as well as mount the filesystem read-only. This will confuse the buffer cache badly. I don't think so -- spec_open checks whether the block device has been mounted in order to prevent this, and I made sure that that check remains in force except when spec_open is called by ffs_mountfs (by adding the FMOUNTING flag). I assumed that the buffer cache will handle multiple read-only mounts because it handles multiple userland reading file descriptors. Also, this may not be the best place to put the code. It make sense to be able to mount a block device multiple times in a read-only fashion, but the code should be in the open for the block device rather then in UFS/FFS, so it can be used with other filesystems and for other purposes. Yes, it's evident that this is true because I had to hack around essentially the same test in both spec_open and ffs_mountfs; removing the checks down from ffs_mountfs so it relies on spec_mount to DTRT would be neater, I think. Tony. -- f.a.n.finchd...@dotat.atf...@demon.nete pluribus unix To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
NFS authentication
I am wondering where the NFS authentication is done in FreeBSD. Is it done by the NFS daemon mountd (or other daemon) or within the kernel? Can anyone give me a pointer? Thanks a lot. -- Zhihui Zhang. Please visit http://www.freebsd.org -- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: Dell PERC LVD card (Power Edge Raid Controller)
Thomas Uhrfelt wrote: An excellent initiative! I think there are many administrators/system managers out there with a huge stack of unused goods lying on the shelves to no use at all. Perhaps there should be a database where interested devicedriver programmers could post their needs and sysadminds could post their unneeded hardware on. Perhaps in that way we could speed up the development of HW drivers for FreeBSD? Any thoughts on this one? Kelly Yancey wrote: This is indeed a good idea. If nobody else has stepped up to the challenge, I will try to have such a site up by the end of the week (Well, let's make it Sunday...gives me the weekend to work on it too :) ). I'll keep everyone posted. Kelly I have gotten a few e-mail today pointing out that I didn't post anything about my progress on this web site on Sunday (like I promised above). I'm not dead, just a little delayed. :) Anyway, I'm making pretty good headway on the site and should have it wrapped up over the next couple of days. When I'm done, I'll let everyone know so maybe we can start geting more hardware into developers' hands! Kelly ~kby...@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
debugging a proc's kernel stack...
Hi, I want to see where some a deadlock is occurring in the kernel. I've got a dump with a bunch of processes in the inode or namecache state. Can anybody give me a hint about how to find a proc's kernel stack - so that I can find out what these kernel was doing for these processes when it locked up... (see repeated deadlocks in FS ... on the smp list for more info about the problem)... thanks alot, greg To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf shortage situations (followup)
!I think that what needs to be done is to split the problem in two. First, !allow the mbuf routines to return a failure even with M_WAIT. If M_WAIT !is used, it simply means 'try harder, sleeping a bit if necessary'. This !requires ensuring that all the networking code deal with the failure !case - a time consuming but straightforward task. If a failure occurs, !one simply drops the packet, not the connection or anything else drastic. !just the packet. Yes, these is mainly the part I've been working on recently. The sleeping and what not (as I'm sure you've seen from the patches if you looked at them) has already been completed. Adding a counter that will expire and return a pre-defined error is trivial, in this case. The only real issue here (if we can call it that) is get _all_ the networking code to recognize this. Anyone want to help? :-) ! !The second problem that needs to be addressed is resource exhaustion. !For example, allocating thousands of connections and socket-opting their !buffers as large as possible, or programs such as syslog accepting new !connections ad-infinitum. This is a harder problem to fix properly, !but a lot of the various issues such as those with syslog can be dealt !with in userland rather then the kernel. ! ! -Matt ! I agree. The issue here is somewhat related (if I understand your explanation correctly) to [local] processes attempting to grab a lot of socket buffer space. I was a little less concerned with this issue since, as I previously mentionned, Brian Feldman is working on limiting socket buffer space. Nonetheless, if we do not consider limiting, here's what I believe will need to be done: As explained above, when we run out of mbufs and/or mbuf clusters (and some are needed), if we are M_WAIT (when processes socket opt their buffers as large as possible, the call is usually with M_WAIT), we will end up tsleep()ing for certain periods of time, until our counter expires and we return our pre-defined error (as mentionned above). When we do return this error, however, the caller (for instance, we can consider sosend() the caller -- which, if I remember correctly, is one of the callers to MGET() when we setsockopt a large buffer and consequently write() to this socket), will also have to know how to properly deal with this error (e.g.: kill the process?). Killing the process may seem somewhat sadistic to some ( :-) ), but remember that if we do get to the point where 'normal' local processes eat up so much buffer space that we run out, we should probably be increasing NMBCLUSTERS and/or maxusers anyway. As for script weenies, I hope that Brian (and whomever else may be working on it) gets that sockbuf limiting code done, because, to be quite honest, I don't think that script kids having to comprimise more than one account just so they can DoS a box will be much of an issue (if worse comes to worse, we can limit per gid -as opposed to per uid). With exhaustion attacks such as these, we're better off just limiting. Regards, Bosko Milekic. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: mbuf shortage situations (followup)
On Mon, 13 Sep 1999, Garrett Wollman wrote: !On Sun, 12 Sep 1999 23:19:13 -0400 (EDT), Bosko Milekic bmile...@dsuper.net said: ! ! This message is in MIME format. The first part should be readable text, ! while the remaining parts are likely unreadable without MIME-aware tools. ! Send mail to m...@docserver.cac.washington.edu for more info. ! !It would be preferable if text were sent as text, since MIME-encoded !patches require more effort to read. ! I deffinately agree. This is obviously my mistake, and I was somewhat in a rush, very lagged (modem, eurgh), using pine, and made several [dumb] typos in the 'Attatchement' field. ! I'm also aware of the possiblity of some people not liking the ! fact that we tsleep() forever (e.g. tsleep(x,x,x,0)). ! ! !I don't have any problem with sleeping forever -- but I am concerned !about the possibility of deadlock, especially when client-NFS is !involved. If the problem just moves around and has harder-to-recover !symptoms, the change isn't helping. Well, the main purpose of the code is to basically sleep until something is freed after we've already exhausted the mb_map arena (as I'm sure you've seen if you were able to grab the attachements). This is really a-la-limite stuff. In other words, if 'normal' local programs are having trouble because of mb_map exhaustion, then maxusers nmbclusters would have to be augmented. ! !The 4.3BSD code had two different behaviors: ! ! - For clusters, if M_WAIT was specified and there was no space !left in mb_map, it panicked. However, m_clalloc was never called with !M_WAIT, so that panic was effectively dead code. Hmmm. If m_clalloc was never called with M_WAIT, then all the code calling m_clalloc deffinately checked its return value. It probably had specific ways to deal with m_clalloc returning failures, too? ! ! - For mbufs, if M_WAIT was specified and there were no mbufs !available, it would sleep at PZERO - 1 (which was interruptible). ! !In 4.3, the code was able to deal with cluster allocation failing. We !have a somewhat different situation now, because many network !interface devices have less-flexible DMA mechanisms which don't allow !packet reception into non-contiguous buffers, so we need to have at !least a certain number of clusters available for this purpose. Exactly. This is the next challenge. As for things being interruptable, as I mentionned to a reply to Matt Dillon just a few seconds ago, getting the tsleep to occasionally expire is trivial. As you say above, it's dealing with the failure that is the issue. ! !-GAWollman ! !-- !Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same !woll...@lcs.mit.edu | O Siem / The fires of freedom !Opinions not those of| Dance in the burning flame !MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick ! Cheers, Bosko Milekic. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Multiple NAT alias addresses
hello .. We're trying to turn up a firewall box running NAT with multiple external IPs. I added the alias and set up natd.conf as follows: use_sockets yes same_ports yes # # machine1 redirections #redirect_port tcp 192.168.2.237:ssh 1.2.3.4:ssh #redirect_port tcp 192.168.2.237:smtp 1.2.3.4:smtp #redirect_port tcp 192.168.2.237:pop3 1.2.3.4:pop3 #redirect_port tcp 192.168.2.237:imap4 1.2.3.4:imap4 # machine2 redirections redirect_port tcp 192.168.2.201:ssh 1.2.3.5:ssh redirect_port tcp 192.168.2.201:http 1.2.3.5:http I start natd with: natd -f /etc/natd.conf -n fxp0 where fxp0 is the public-side interface. Restarting natd with this configuration causes it to block everything. Does natd support multiple alias addresses, or am I missing something obvious? This is a production situation so doing test runs for logs is difficult. I can get more info in ~30 minutes, but if someone can note any inconsistencies that would be great. Doug White Internet: dwh...@resnet.uoregon.edu| FreeBSD: The Power to Serve http://gladstone.uoregon.edu/~dwhite| www.freebsd.org To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Multiple NAT alias addresses
On Mon, Sep 13, 1999 at 05:48:11PM -0700, Doug White wrote: hello .. We're trying to turn up a firewall box running NAT with multiple external IPs. I added the alias and set up natd.conf as follows: use_sockets yes same_ports yes # # machine1 redirections #redirect_port tcp 192.168.2.237:ssh 1.2.3.4:ssh #redirect_port tcp 192.168.2.237:smtp 1.2.3.4:smtp #redirect_port tcp 192.168.2.237:pop3 1.2.3.4:pop3 #redirect_port tcp 192.168.2.237:imap4 1.2.3.4:imap4 # machine2 redirections redirect_port tcp 192.168.2.201:ssh 1.2.3.5:ssh redirect_port tcp 192.168.2.201:http 1.2.3.5:http I start natd with: natd -f /etc/natd.conf -n fxp0 where fxp0 is the public-side interface. Restarting natd with this configuration causes it to block everything. So, without redirect_port's it works OK? Have you tried to run it in the foreground? (`natd -v') Does natd support multiple alias addresses, or am I missing something obvious? Definitely supports! BTW, what version you are on? -- Ruslan Ermilov Sysadmin and DBA of the r...@ucb.crimea.ua United Commercial Bank, r...@freebsd.orgFreeBSD committer, +380.652.247.647Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: debugging a proc's kernel stack...
On Monday, 13 September 1999 at 20:00:02 +, greg wrote: Hi, I want to see where some a deadlock is occurring in the kernel. I've got a dump with a bunch of processes in the inode or namecache state. Can anybody give me a hint about how to find a proc's kernel stack - so that I can find out what these kernel was doing for these processes when it locked up... (see repeated deadlocks in FS ... on the smp list for more info about the problem)... Take a look at the .gdbinits in /usr/src/sys/modules/vinum. There's a little bit of documentation in vinum(4), but not really enough. The functions you might want are (extracted from gdb's help user): btp -- Show a backtrace for the process whose pid is specified as a parameter btpa -- Show backtraces for all processes in the system btpp -- Show a backtrace for the process previously selected with 'defproc' btr -- Show a backtrace from the ebp address specified defproc -- Specify a process for btpp and fr commands fr -- Show the frame of the stack of the process previously selected with 'defproc' Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Command-line editing [was NetWare client in -current]
On Mon, 13 Sep 1999 09:23:36 BST, Dominic Mitchell wrote: On Fri, Sep 10, 1999 at 11:15:12AM -0700, Parag Patel wrote: Growing up programming on a KL-10, I still think the correct place for line-editing is in the driver. Hell - it's already doing basic erase/kill line editing as it is. Then you don't have to hack every command-line app to get line-editing. Yeah, but how do you specify completion then? Same way termcap/termlib would be handled. :) I was toying with an ioctl or some-such that gave the termcap info to the driver in one block. Shouldn't be any harder to run a small daemon responsible for returning file-name completion info to the driver, assuming it can't get the info by itself from the file-system layer. The KL even did command *option* completion. It partly loaded an executable - just enough to run its command-line parsing stuff - to handle expanding options and displaying help. 'Course it cheated on the termcap/lib stuff. You could use any terminal as long as it was a VT100-compatible one. Pity most OSes don't even match TOPS in many areas. Unix went here a long time ago and backed out of it. Have a look at the paper http://www.cs.princeton.edu/~jlk/kornshell/doc/vhll.ps.gz (linked from www.kornshell.com) in particular, the history section. Yeah, I read it, but it doesn't say why they never put it in the driver. Just that he put it in ksh because the driver work had stalled for whatever reason. On Mon, 13 Sep 1999 09:09:52 PDT, Matthew Jacob wrote: Yeah, and this is why VMS 4.X (early) had a terrific security bug- if you type '#' (or was it '') as the first character after you logged in, your accounting records for that session were wiped. Strawman. Really, just because one crappy OS has a crappy driver with one bug is no reason to completely throw out the idea. No, a driver is *not* the place to put this kind of fooling around. But making each and every complex command-line app have to deal with this itself or link to N different command-line editing libraries *is* OK? And why is the driver performing backspace and kill processing and all sorts of other complicated crap like cooked vs raw? Either the driver should be really dumb and hand off *everything* through some user-level filter/app, or it should be capable of doing everything itself. Moving vpty handling out of the kernel would be a good start. -- Parag Patel To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
aio_*
While reading through (at least trying to... I wish there was some sort of kernel documentation available, the entry fee is very high) the aio_* calls, I had a few questions to clear up my understanding: 1) Do they only work on files? The only implementation I see is in the VFS layer. 2) It is my understanding that it uses an aio daemon running as a kernel thread (the aio_daemon() call kind of give that one away). It seems as if this can be almost entirely done in user space. More important to what I am trying to do, it seems as if aio_* does not give peak latency or throughput performace, since the aio_daemon has to compete for resources along with all other processes. Should aio_* be used for applications that have high performance requirements? What does aio_* get you above having a seperate thread pumping in/out data? -jason To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
