Re: IDE quirk in 3.2-STABLE kernel ?
When moving the CDROM to master though can cause problems. I had a Chaintech 5TDM board which refused to acknowledge a CDROM as secondary master. I thought it was a bug in FBSD since RH Linux could detect my CDROM as a secondary slave (only device on the controller). I never got a straight answer as to why it didnt work and why it shouldnt be changed or supported. I did get an answer from someone that said that it should work in 3.0+, I tried and it didnt work. *shrug* probably just my mobo and FBSD didnt like each other in this regard. regards, chris Vince Vielhaber wrote: On Wed, 4 Aug 1999, Biju Susmer wrote: hi, I tried yesterday to make the kernel understand my CD ROM drive.. but it refused. Here is the dmesg (of boot -v)... is my config wrong or i missed something? The drive is Acer 32X and connected as secondary slave. It is seen by Win98 and BIOS. Can someone help? You have the CD connected as the secondary slave and no secondary master. That's the problem. It's an illegal configuration as the IDE controller is actually on the drive itself. Move the jumper on the CD to master and it'll be recognized. Vince. -- == Vince Vielhaber -- KA8CSH email: [EMAIL PROTECTED] flame-mail: /dev/null # include std/disclaimers.h TEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message -- Christopher Day E-Mail [EMAIL PROTECTED] Homepage http://www.geocities.com/TimesSquare/Lair/1218 when the rain/when the children reign/keep your conscience in the dark melt the statues in the park - Fall On Me, REM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Results of investigating optimizing calloc()...
John-Mark Gurney wrote: Dag-Erling Smorgrav scribbled this message on Aug 4: "Kelly Yancey" [EMAIL PROTECTED] writes: [...] Which reminds me - has anyone thought of using DMA for zeroing pages, to avoid cache invalidation? The idea is to keep a chunk of zeroes on disk and DMA it into memory instead of clearing pages "manually". This assumes your disk supports DMA, of course. has anyone looked at using two dma channels tied together to do memory copies? I haven't studied the DMA specs, but from what I know of the dma on x86 machines is that you could tie two dma channels together one to feed the other, and this would allow you to copy memory w/o using the processor... w/ dma channels, we can just make a copy of the base zero page... Im not sure how much relevance this has, but many years ago I was writing video routines, I thought using software initiated DMA to copy pages of memory from one place to another would be a really cool and quick solution. From what I remember you need to set the 0th DMA chanel with a src and dst address, then the number of bytes - set a flag and away she went. It was strange in that the DMA controller could only access the first 1Mb of memory and it couldnt cross 64kb page boundaries. Now AFAIK that has changed slightly and the DMA chip can do up to 128Kb page boundaries, however I'm not sure wether it can do 32bit addressing. However there was a drawback if the CPU had nothing else to do it could actually transfer memory around quicker than the DMA controller (The DMA controller on my PC was going at ISA bus speed ~8Mhz) Not sure what it does now, must go at at least 33Mhz for PCI DMA's. Also now that I remember it, the 0th DMA channel back then was also used a DRAM refresh timer going off every few milliseconds to keep the charges up on the DRAM's. Weird eh? Anyways thats all I can think of. The only way I can see that using DMA to refresh pages as a faster method is if the DMA controller can do it quicker than the CPU which I doubt is likely, also it will only be useful if it can do 32-bit addresses. sorry for the ramble. regards, chris -- Christopher Day E-Mail [EMAIL PROTECTED] Homepage http://www.geocities.com/TimesSquare/Lair/1218 when the rain/when the children reign/keep your conscience in the dark melt the statues in the park - Fall On Me, REM To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fetch: default to passive mode?
"Chuck Youse" [EMAIL PROTECTED] writes: I have a really strong urge to submit a PR to make fetch default to passive mode, instead of requiring a command-line switch ... fetch(1) honors FTP_PASSIVE_MODE. des@des /usr/freebsd/current% lcvs log -r1.31 src/etc/login.conf RCS file: /home/ncvs/src/etc/login.conf,v Working file: src/etc/login.conf head: 1.32 branch: locks: strict access list: symbolic names: RELENG_3_2_PAO: 1.26.2.3.0.2 RELENG_3_2_PAO_BP: 1.26.2.3 RELENG_3_2_0_RELEASE: 1.26.2.3 RELENG_3_1_0_RELEASE: 1.26.2.1 RELENG_3: 1.26.0.2 RELENG_3_BP: 1.26 RELENG_2_2_8_RELEASE: 1.9.2.7 RELENG_3_0_0_RELEASE: 1.22 RELENG_2_2_7_RELEASE: 1.9.2.7 RELENG_2_2_6_RELEASE: 1.9.2.7 RELENG_2_2_5_RELEASE: 1.9.2.3 RELENG_2_2_2_RELEASE: 1.9 RELENG_2_2: 1.9.0.2 keyword substitution: kv total revisions: 43;selected revisions: 1 description: revision 1.31 date: 1999/05/28 11:07:16; author: jkh; state: Exp; lines: +2 -2 Set FTP_PASSIVE_MODE=YES by default in the default login class. = DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP stack hackers take a bow
Bill Fumerola writes: On Tue, 3 Aug 1999, Ted Faber wrote: http://www.sciencedaily.com/releases/1999/08/990802072727.htm The Duke release credits one Andrew Gallatin for a couple quotes. Not only FreeBSD in the news, but one of our own committers. Cool. http://www.dukenews.duke.edu/Research/GIGABIT.HTM Yes, my boss decided he wanted his 15 minutes of fame ;-) I tried hard to get FreeBSD a bigger mention than the rather poorly worded one that ended up coming out, but to little avail. After all, it is the BSD TCP stack that deserves the bulk of the credit; we were basically in the right place at the right time. It was very annoying that the person who wrote the local News Observer article seemed disappointed that we were not running linux probably because of that, didn't mention the OS at all in her article. Cheers, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: [EMAIL PROTECTED] Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP stack hackers take a bow
Bill Fumerola writes: On Tue, 3 Aug 1999, Ted Faber wrote: http://www.sciencedaily.com/releases/1999/08/990802072727.htm The Duke release credits one Andrew Gallatin for a couple quotes. Not only FreeBSD in the news, but one of our own committers. Cool. http://www.dukenews.duke.edu/Research/GIGABIT.HTM Yes, my boss decided he wanted his 15 minutes of fame ;-) I tried hard to get FreeBSD a bigger mention than the rather poorly worded one that ended up coming out, but to little avail. After all, it is the BSD TCP stack that deserves the bulk of the credit; we were basically in the right place at the right time. It was very annoying that the person who wrote the local News Observer article seemed disappointed that we were not running linux probably because of that, didn't mention the OS at all in her article. Yes - I noticed the conspicuous absence of any mention of BSD in the News Observer article. - Dave Rivers - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Multiple versions of FreeBSD on one HDD
Robert Nordier wrote: I assume that if I set the gemoetry in fdisk to be the BIOS figures, that I will lose the other half of the disk? Use 2096/255/63 in sysinstall. That worked! Here is what I did in the end: * set the BIOS disk type to Auto detect in LBA mode * booted 2.2.8 install diskette. Set the disk geometry in fdisk to 2096/255/63. * created three slices. The first two were both 3Gb, a bit smaller than I would have liked, but they both fit within the 1023 logical cylinder boundary. The third slice contained the remaining 10Gb+. About 5Mb of unused space was left at the end. * installed 2.2.8 into partition 1. * booted 2.2.8, and used fdisk to set the disk type to 6 * booted the 3.2 install disk. Checked the geometry settings were the same in fdisk, and set the second slice to be the active partition * installed 3.2 in the second slice * booted 3.2, and used its fdisk to set the partition type of the first slice back to 165 * booted a DOS diskette, and installed os-bs. The changing of the partition type was a necessary step; without this, the 3.2 install would still complain and refuse to make the root file system. Thanks for the help, Robert. Hopefully the summary above will be useful to others as well. g. -- Dr Graham WheelerE-mail: [EMAIL PROTECTED] Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security SpecialistsWWW:http://www.cequrux.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP stack hackers take a bow
On Thu, 5 Aug 1999, Andrew Gallatin wrote: It was very annoying that the person who wrote the local News Observer article seemed disappointed that we were not running linux probably because of that, didn't mention the OS at all in her article. It's sad it has to be that way. I can't think of another product that is treated so poorly in the wake of another's success. "What you broke a land speed record? Well, were you driving a Ford? No, well, we just won't mention that you were driving a Chevy." -- - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Memory Tuning
What type of memory do routing table entries use, and how can they be tuned? I've got a machine with 64M, and it will only allocate 10M to the routing table no matter what I set maxusers to. The full table is only 17M, so it should fit easily. Even if I have to change something in param.c...Im just at a loss as to what it needs. Dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: login.conf restrictions for suid processes possible? (fwd)
On Thu, 5 Aug 1999, Mike Smith wrote: I am working on some resource limit stuff and would like to be able to use login.conf to restrict the number of cgi processes that certain users can run. Unfortunately, the proprietary cgi product we use is owned by root and suid's to the user who owns the script that it is called to run. (This is not what I would call a "good idea," but it's what I have to work with.) I've created a login class with the appropriate permissions, and if I put a test user in that class and test its limits with normal system processes (like ls, sleep, etc.) it follows all the rules. However when I start miva (proprietary cgi) processes for scripts owned by that user, it ignores the limits, presumably because the process starts its life as root. S, the question is, how can I do what I want to do, and if I can't do it with login.conf does anyone have any other suggestions? Specifically I need to restrict the amount of ram and the number of processes on a per user basis. I'm working on a -current system, but I don't think this issue bears directly on -current. You need to pester the vendor to correctly switch limits when they switch UIDs. Alternatively, if this is unlikely _and_ the application is dynamically linked, you could produce a library containing patched set*id functions and force it into the app using LD_PRELOAD. Grrrfl. Ok, that's what I thought, but I do appreciate the confirmation. We have a pretty good relationship with the vendor so I'll take that route first. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: login.conf restrictions for suid processes possible? (fwd)
On Thu, 5 Aug 1999, John Polstra wrote: In article [EMAIL PROTECTED], Mike Smith [EMAIL PROTECTED] wrote: I am working on some resource limit stuff and would like to be able to use login.conf to restrict the number of cgi processes that certain users can run. Unfortunately, the proprietary cgi product we use is owned by root and suid's to the user who owns the script that it is called to run. (This is not what I would call a "good idea," but it's what I have to work with.) [...] You need to pester the vendor to correctly switch limits when they switch UIDs. Alternatively, if this is unlikely _and_ the application is dynamically linked, you could produce a library containing patched set*id functions and force it into the app using LD_PRELOAD. N.B., LD_PRELOAD won't work if the program is setuid or setgid. I'm not 100% sure from the original post whether that's the case or not. Yes, the program is owned by root, has permissions -rwsr-xr-t and suid's to the user who owns the script it's called to run. I'm aware that the sticky bit is ignored on BSD for executables, but that's how it comes from the vendor so my boss doesn't want to mess with it. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP stack hackers take a bow
On Thu, 5 Aug 1999, Bill Fumerola wrote: On Thu, 5 Aug 1999, Andrew Gallatin wrote: It was very annoying that the person who wrote the local News Observer article seemed disappointed that we were not running linux probably because of that, didn't mention the OS at all in her article. It's sad it has to be that way. I can't think of another product that is treated so poorly in the wake of another's success. Hmmm... OS/2 maybe? :) (Which is not to say that IBM didn't work very hard at shooting themselves in their collective feet at every opportunity.) But seriously folks, this kind of thing happens all the time in the computer business. The best way to handle it is to keep smiling and talk to the ones who will listen, and report accurately. The word is getting out slowly. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
possible syslogd bug?
I have a dedicated syslog machine runnign 3.2 and vanilla syslogd (started with -vv flags). After running for a few day the file would grow (this time file was ~40MB) and syslogd would stop writing to a file and go into a weird state. Here is the ktrace of "hang" syslogd before I did 'reboot' dlog# kdump 93 syslogd PSIG SIGALRM caught handler=0x804afb8 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL gettimeofday(0xefbfc84c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL setitimer(0,0xefbfc844,0xefbfc834) 93 syslogd RET setitimer 0 93 syslogd CALL sigreturn(0xefbfc880) 93 syslogd RET sigreturn JUSTRETURN 93 syslogd CALL poll(0xefbfc94c,0x1,0x9c40) 93 syslogd PSIG SIGALRM caught handler=0x804afb8 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL gettimeofday(0xefbfc84c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL setitimer(0,0xefbfc844,0xefbfc834) 93 syslogd RET setitimer 0 93 syslogd CALL sigreturn(0xefbfc880) 93 syslogd RET sigreturn JUSTRETURN 93 syslogd CALL poll(0xefbfc94c,0x1,0x9c40) 93 syslogd PSIG SIGTERM caught handler=0x804b178 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL sigprocmask(0x1,0x2001) 93 syslogd RET sigprocmask 16385/0x4001 93 syslogd CALL gettimeofday(0xefbfc08c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL writev(0x12,0xefbfc04c,0x7) 93 syslogd GIO fd 18 wrote 64 bytes "Aug 3 21:52:25 syslog.err dlog syslogd: exiting on signal 15 " 93 syslogd RET writev 64/0x40 93 syslogd CALL writev(0x1d,0xefbfc04c,0x7) 93 syslogd GIO fd 29 wrote 64 bytes "Aug 3 21:52:25 syslog.err dlog syslogd: exiting on signal 15 " 93 syslogd RET writev 64/0x40 93 syslogd CALL sigprocmask(0x3,0x4001) 93 syslogd RET sigprocmask 24577/0x6001 93 syslogd CALL unlink(0x804c9e5) 93 syslogd NAMI "/var/run/log" 93 syslogd RET unlink 0 93 syslogd CALL exit(0x1) System also shows syslogd is in poll() state when it hangs .. I did not see anything wrong with syslogd.c when I looked. The file is now at 62MB, I see if I can debug this further next time syslogd hangs. -- yan P.S. -- Yes, *.* is going into that file ;) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
BSD XFS Port BSD VFS Rewrite
I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of "The Design and Implementation of the 4.4BSD Operating System" still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: TCP stack hackers take a bow
%Unmodified FreeBSD TCP at 1Gb/s. % %http://www.sciencedaily.com/releases/1999/08/990802072727.htm That is so very cool. There is a separate war going on optimizing bandwidth, latency, and QoS for IIOP, i.e. CORBA's usual protocol. Against all of the heavyweights, RTOS's etc. etc., linux is looking very good. Surprisingly good. Thus... Cheers, Russell To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
more crashes and fixes (linux/svr4/ibcs2)
Thanks to our Peter Holm's stress testing suite, I found a pretty bad
bug in all current emulation (*) code. They all share a common base, and
the problem is in the pathname translation code.
What it amounts to is the inherent assumption that all passed in paths
are valid addresses. This is not true, and the problem occurs when the
stackgap memory (used when we pass the path to good ol' namei/NDINIT)
does not contain valid data. This can happen very easily:
1. A bad address is passed to the kernel with a syscall, i.e.
linux_uselib().
2. Linux_uselib() calls a macro which calls linux_emul_find().
3. Linux_emul_find() notices that the address is invalid
(via return of EFAULT from copyinstr()) and returns that.
4. The code ignores the error and continues on its merry way,
assuming that the stackgap contains valid data, but it
will only get to problems. namei() will crash when it
gets a page fault trying to copyinstr() from UIO_SYSSPACE.
Here's my fix:
--- src/sys/i386/linux/linux_util.h.origThu Aug 5 18:32:02 1999
+++ src/sys/i386/linux/linux_util.h Thu Aug 5 19:03:27 1999
@@ -83,10 +83,17 @@
int linux_emul_find __P((struct proc *, caddr_t *, const char *, char *,
char **, int));
-#define CHECKALTEXIST(p, sgp, path) \
-linux_emul_find(p, sgp, linux_emul_path, path, (path), 0)
+#define CHECKALT(p, sgp, path, i) \
+ do {\
+ int _error; \
+ \
+ _error = linux_emul_find(p, sgp, linux_emul_path, path, \
+ path, i); \
+ if (_error) \
+ return (_error);\
+ } while (0)
-#define CHECKALTCREAT(p, sgp, path) \
-linux_emul_find(p, sgp, linux_emul_path, path, (path), 1)
+#define CHECKALTEXIST(p, sgp, path) CHECKALT(p, sgp, path, 0)
+#define CHECKALTCREAT(p, sgp, path) CHECKALT(p, sgp, path, 1)
#endif /* !_LINUX_UTIL_H_ */
Either this or a similar fix will be necessary for svr4, ibcs2, and linux.
(*) I said emulation because we are emulating the ABI for another OS.
Therefore, linux.ko, svr4.ko, and ibcs2*.ko are all "emulators."
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: How the `struct linker_set' is used in building an ELF kernel?
In article [EMAIL PROTECTED], Joe Jih-Shien Lu [EMAIL PROTECTED] wrote: I started studying 3.2-stable kernel source for days. There are some questions I cannot figure out in an ordinary C programmer's point of view: * In cninit(), it references a global variable `cons_set' of the type `struct linker_set,' but I don't see its definition in any of the source files except the setdef0.c generated by /usr/bin/gensetdefs. It is defined by the .long asm psuedo-op, and seems to have the size of 4 bytes. However, in /sys/i386/i386/cons.h, it is declared as of the type `struct linker_set' which is 8-byte long. This inconsistency confused me. * Similar problem is encountered when I'm poking around the system initializing for-loop in main(). sysinit_set, declared as struct linker_set, is referenced, but I can't get into the way how this variable is initialized. I guess it is the linker who did all the magic, since the comment in /sys/sys/linker_set.h mentioned about it. After studying the linker script (/sys/i386/conf/kernel.script) and ld.info, though, I still don't have any idea about the details behind the scene. Linker sets are basically arrays of pointers that are constructed by the linker using values that can come from many object files. The first word contains the number of elements (pointers) in the set. Then come the pointers themselves. Finally, a NULL pointer appears at the end of the set. The old a.out linker supported linker sets directly, and did all the bookkeeping necessary to keep track of the set sizes and so forth. The ELF linker does not directly support linker sets. However, it does support an arbitrary number of independent sections. Using that along with a little help from gensetdefs, we can get a.out-style linker sets using the ELF tools. setdef0.o must appear first on the linker command line. It contributes the leading count word to each set. Then come the "normal" object files, which may contribute pointers to various sets. These are just appended to special sections, one per linker set. Finally comes setdef1.o, which emits the terminating NULL pointers. I notice that gensetdefs looks for the sections by the `.set.'-prefixed name in all the ELF kernel object files, and produces the setdef[12].c accordingly. Does the `.set.'-prefixed section name have any special meaning in an ELF object file? No, it is just a convention we use for naming the sections that contain linker sets. gensetdefs knows this convention, and so do the macros in sys/linker_set.h. The compiler, assembler, and linker aren't aware of anything special about the names. John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "No matter how cynical I get, I just can't keep up."-- Nora Ephron To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: more crashes and fixes (linux/svr4/ibcs2)
On Thu, 5 Aug 1999, Brian F. Feldman wrote:
Correction:
--- src/sys/i386/linux/linux_util.h.orig Thu Aug 5 18:32:02 1999
+++ src/sys/i386/linux/linux_util.h Thu Aug 5 19:03:27 1999
@@ -83,10 +83,17 @@
int linux_emul_find __P((struct proc *, caddr_t *, const char *, char *,
char **, int));
-#define CHECKALTEXIST(p, sgp, path) \
-linux_emul_find(p, sgp, linux_emul_path, path, (path), 0)
+#define CHECKALT(p, sgp, path, i)\
+ do {\
+ int _error; \
+ \
+ _error = linux_emul_find(p, sgp, linux_emul_path, path, \
+ path, i); \
+ if (_error) \
This should only be
if (_error == EFAULT)
+ return (_error);\
+ } while (0)
-#define CHECKALTCREAT(p, sgp, path) \
-linux_emul_find(p, sgp, linux_emul_path, path, (path), 1)
+#define CHECKALTEXIST(p, sgp, path) CHECKALT(p, sgp, path, 0)
+#define CHECKALTCREAT(p, sgp, path) CHECKALT(p, sgp, path, 1)
#endif /* !_LINUX_UTIL_H_ */
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeMWare for FreeBSD??
On Thu, Aug 05, 1999 at 06:42:39PM -0700, Donald Burr wrote: What is FreeMWare? It sounds like a free / Open source implementation of the VMware virtual machine. Do you have an URL that I could look up? This sounds interesting! It's at www.freemware.org. I should say, though, that it's very much pre-alpha at the moment; no downloadables yet, but they do have a mailing list you can join. -lee -- ++ | Lee Cremeans -- Manassas, VA, USA (WakkyMouse on WTnet) | | [EMAIL PROTECTED] | http://wakky.dyndns.org/~lee | To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeMWare for FreeBSD??
Thanks. I wasn't expecting any available software at the moment, I just wanted a URL so that I could watch over this project and keep track of it. Definitely something I"m interested in. Donald Burr [EMAIL PROTECTED] WEB: http://www.Powered-By.AC/ PO Box 91212, Santa Barbara, CA 93190-1212 Tel:(805)957-9666 FAX:(800)492-5954 Member and software developer with The FreBSD Project - http://www.FreeBSD.ORG/ *** FreeBSD *** A FREE, 32 Bit UNIX OS for PC's -- The Power to Serve! On Thu, 5 Aug 1999, Lee Cremeans wrote: It's at www.freemware.org. I should say, though, that it's very much pre-alpha at the moment; no downloadables yet, but they do have a mailing list you can join. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: m68k Support in FreeBSD (old thread)
On Mon, 19 Jul 1999, Jordan K. Hubbard wrote: website (http://www.freebsd.org/~green/FreeBSD-68k.txt). In about two weeks I'll have a spare Macintosh IIsi and would like to have a run at FreeBSD on it. So, to the point, where can I get it? :) I'd say that's a question for Grant Stockly, the person mentioned in green's web-cited message. It's certainly not part of FreeBSD and whether it ever will be is a matter still subject to debate. Prior to posting to -hackers, I had emailed him, I tried again after receiving this message and again, no response. (I used [EMAIL PROTECTED]) Is there a better way to contact this individual? Does anyone have a copy of the port? I really don't want to have to install NetBSD on this Mac :) Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cvs
Can someone tell me how to make a cvs archive work for users that aren't the owner of the archive, the way that it works on Freefall? I *am* doing this for a cvsup maintained FreeBSD archive, but not freefall, and I need to get one user, who is not the archive owner, to be able to be able to do checkouts and diffs (no source changes, but it needs to be able to lock directories for checkouts). Thanks. +--- Chuck Robey | Interests include any kind of voice or data [EMAIL PROTECTED] | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: NSS Project
On Thu, 5 Aug 1999, John Polstra wrote:
In article [EMAIL PROTECTED],
Brian F. Feldman [EMAIL PROTECTED] wrote:
Mind pointing me to the technical reason why (I'm sure you've explained
it before) we can't use the dl* calls in any way without linking
against ld-elf.so.1? I mean, have them in libc, for instance...
The versions in libc are just stubs. Take a look at
"src/lib/libc/gen/dlfcn.c". The implementations are in the dynamic
linker.
Yes. I said "have them" as in "we could", not "we do have them in libc..."
One option I don't think anyone's brought up: why don't we _just_
have ld-elf.so.1 in the root, but not libraries? That way, we
don't bloat root excessively, but we can let people depend on
being able to build -static/-Bstatic binaries that make everything
static except the rtld? And modify gcc/ld to have static link with
the rtld, so we have the benefit of those calls, can have static
binaries still, and be able to depend on having an rtld (even for
single-user mode.)
I think you have some misconceptions about how it all fits together.
Executables aren't "linked with" the dynamic linker. It's a
separate shared object that is loaded directly by the kernel. It
gets control before the main executable gets control. Look at
"src/sys/kern/imgact_elf.c" and at the dynamic linker.
I suppose I do have some misconceptions. I'll look at the "FreeBSD" ELF
image activator. I know how ld-elf gets control first, and calls .init
things, etc. But:
{"/usr/src/contrib/egcs"}$ grep -R ld-elf .
./gcc/config/alpha/freebsd.h: %{!dynamic-linker:-dynamic-linker
/usr/libexec/ld-elf.so.1}} \
./gcc/config/i386/freebsd.h:%{!dynamic-linker: -dynamic-linker
/usr/libexec/ld-elf.so.1}} \
./gcc/config/i386/freebsd-elf.h:%{!dynamic-linker:-dynamic-linker
/usr/libexec/ld-elf.so.1}} \
What should that tell me exactly?
Also, programs that are linked (at "ld" time) with dynamic libraries
are different from programs that are linked with static libraries.
I.e., "ld" does very different things in the two cases. You can't
take a statically-linked program and suddenly decide to treat it as
dynamically-linked at runtime. It's too late at that point.
Of course, but you can have a pseudo-static binary, one that only
needs ld-elf.so.1 but not libc, etc.
Finally, shared "libraries" aren't really libraries at all in the
traditional sense. They're monolithic whereas traditional archive
libraries are made up of separate object files which are subsetted by
the linker.
Mm-hmm. ld -Bshareable as opposed to ar rc.
To really understand the issues I think it's necessary to read through
the dynamic linker sources and understand what it's doing. There used
to be books that described how it all worked (Prentice-Hall "System V
Application Binary Interface"), but as far as I know they're out of
print now.
I just think we're not seeing eye to eye.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"No matter how cynical I get, I just can't keep up."-- Nora Ephron
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
[EMAIL PROTECTED] _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Excessive assembly code ?
Taking a quick look at /usr/src/sys/i386: find . -name *.s | xargs wc -l 44 ./svr4/svr4_locore.s 216 ./apm/apm_setup.s 24 ./linux/linux_locore.s 461 ./isa/apic_ipl.s 1057 ./isa/apic_vector.s 168 ./isa/icu_ipl.s 224 ./isa/icu_vector.s 387 ./isa/ipl.s 113 ./isa/vector.s 59 ./i386/bioscall.s 340 ./i386/exception.s 192 ./i386/globals.s 1000 ./i386/locore.s 319 ./i386/mpboot.s 555 ./i386/mplock.s 310 ./i386/simplelock.s 1636 ./i386/support.s 833 ./i386/swtch.s 190 ./i386/vm86bios.s 8128 total I wonder if so much assembly code is really necessary for FreeBSD. One argument for minimal usage of assembly code is that it is easier to code non trivial algorithms in C. One such example is the scheduler. Since the decision about which process is going to run next is decided in assembly code, it is restricted to a relatively dumb algorithm of scanning the runqs and picking one. If the mechanism (i.e nuts and bolts of the context switch) is coded in assembly and the policy (which process to pick next) is done in C, the code would be much more maintainable, IMO. How do people feel about it here ? -Arun To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Adding disks -the pain. Also vinum
On Fri, Aug 06, 1999 at 10:53:54AM +0930, Greg Lehey wrote: On Tuesday, 3 August 1999 at 23:20:45 +0200, Bernd Walter wrote: On Tue, Aug 03, 1999 at 03:59:46PM +0930, Greg Lehey wrote: On Tuesday, 3 August 1999 at 8:12:17 +0200, Bernd Walter wrote: For UFS/FFS there is nothing worth seting the stripesize to low. It is generally slower to acces 32k on different HDDs than to acces 64k on one HDD. It is always slower where the positioning time is greater than the transfer time for 32 kB. On modern disks, 32 kB transfer in about 300 µs. The average rotational latency of a disk running at 10,800 rpm is 2.8 ms, and even with spindle synchronization there's no way to avoid rotational latency under these circumstances. It shouldn't be the latency, because with spindlesync they are the same on both disks if the transfer is requested exactly the same time what is of course idealized.. Spindle sync ensures that the same sectors on different disks are under the heads at the same time. When you perform a stripe transfer, you're not accessing the same sectors, you're accessing different sectors. There's no way to avoid rotational latency under these circumstances. We are talking about the same point with the sme results. I agree you will only access the same sectors in some special cases. Lets say 2 Striped disks with 512 Byte stripes and FSS with 1k Frags. The point is that you have more then a single transfer. With small transfers spindle sync is able to winback some of the performance you have lost with a to small stripe size. No, this isn't correct, unless you're running 512 byte stripes. In That's what I meant with a 'to small stripe size' this case, a single-stripe transfer of, say, 8 kB with the disks above would take about 7 ms total latency (same as with a single disk), but the transfer would take less time--5 µs instead of 80 µs. You'd need 16 disks, and you'd tie them all up for 7 ms. And this doesn't consider the times of SCSI command setup and such. In the rare case you need max bandwith for only one Aplication and one stream I like to hear that all drives are tied up in the job. Basically, this is not the way to go if you have multiple clients for your storage. Look at http://www.lemis.com/vinum/problems.html and http://www.lemis.com/vinum/Performance-issues.html and for more details. Spindle Sycronisation won't bring you that much on modern HDDs - I tried it using 5 Seagate Elite 2.9G (5,25" Full-Height). It should be useful for RAID-3 and streaming video. I case of large transfers it will make sense - but FFS is unable to set up big enough requests. No, this is a case where you're only using one client, so my argumentation above doesn't apply (since you're reading sequentially, so latency is no longer an issue). I don't know what bandwith streaming video needs, but If you need sdditional bandwith of all used disks the first thing to do is linearising access to the disks. Multifileaccess often breaks linearisation. All what I trid to say is that it is hopeless to expect much more bandwith than a single disk in single process access. As an example: Yesterday I was asked if 6 old striped disks would be faster for cvsup than one of his modern disks because it sometime needs more than one telephone unit. The answer is no. cvsupd (if run regulary) spends most of its time sending The directory content of the destination. Usually there are no other programms accessng any disks at the same time, so you can benefit only a very small bit from additional drives. Maybe the additional block cache on the drives and for updating atime. Beleave it or not multiple files are accessed in servers and maybe under some windomanagers, but on many home and desktop machines it happens only rarely. I personaly use as an example 7 200M IBM Disks striped to one volume (They all have LEDs :). The only way for to utilize nearly all in a sensefull way is writing with softupdates enabled. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fetch: default to passive mode?
On 06-Aug-99 John-Mark Gurney wrote: metriclient-1,ttype,/tmp,501#tail squid.access 933914913.491 3750 127.0.0.1 TCP_MISS/200 3816 GET ftp://ftp.cdrom.com/config.txt - DIRECT/ftp.cdrom.com text/plain sure looks like it uses the http proxy, and this is on 3.0-R... Hmm.. sneaky :) I should have read the man page more thoroughly it would seem. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: NSS Project
Mm-hmm. ld -Bshareable as opposed to ar rc. This demonstrates a superficial understanding of the process, nothing more. I just think we're not seeing eye to eye. I'd be more inclined to say that John simply understands this where you don't. Go study up, then come back and engage the poor guy in debate if you genuinely feel you have a solution to offer to this already already much-discussed (see the mail archives) issue. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: m68k Support in FreeBSD (old thread)
On Thu, 5 Aug 1999, James Howard wrote:
Prior to posting to -hackers, I had emailed him, I tried again after
receiving this message and again, no response. (I used [EMAIL PROTECTED])
Is there a better way to contact this individual? Does anyone have a copy
of the port?
I really don't want to have to install NetBSD on this Mac :)
Worse things could happen :^)
I haven't heard from him either (since I sent out my first inquiry July
19th). But all things considered it should be a bit easier to port
NetBSD/mac68k to FreeBSD than it would with the Alpha bits, considering
that you can setup a m68k-aout cross compiler pretty easily ('course easy
is a relative term).
FWIW, NetBSD works quite well on mac68k, but the biggest problem so far is
the lack of virtual consoles (dt is awful).
- alex
You better believe that marijuana can cause castration. Just suppose your
girlfriend gets the munchies!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
Biju Susmer wrote: Regardless, you have to have 1 master and 0 or 1 slaves one every IDE controller. You can't run a controller with just a slave. I dont think it should be a problem.. Since other OSs can work with this configuration without any problem, why FBSD should refuse this configuration? When i was using 2.2.7-stable, FBSD used to recognize my CDROM *sometimes* as slave, not always. Because it's wrong. If you don't believe me, buy a copy of the spec. Why should we waste valuable developer time trying to support mis-configured hardware? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
On 06-Aug-99 Wes Peters wrote: Because it's wrong. If you don't believe me, buy a copy of the spec. Why should we waste valuable developer time trying to support mis-configured hardware? Since when has PC hardware followed the specs? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum PGP signature
Re: NSS Project
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote: Mm-hmm. ld -Bshareable as opposed to ar rc. This demonstrates a superficial understanding of the process, nothing more. I know exactly how an ar archive is made of all the non-PIC .o files and a ranlib works. I know what happens when ld puts together position- independent-code (which is position-independent because it uses the GOT) and generates a shared library. I know how GCC only includes the .o files from an ar library archive which it needs and nothing more. I know that the dl* functions in libc itself are just stubs. All I don't know is why we can't load ld-elf.so.1 for static executables as well as "dynamic" ones. I just think we're not seeing eye to eye. I'd be more inclined to say that John simply understands this where you don't. Go study up, then come back and engage the poor guy in debate if you genuinely feel you have a solution to offer to this already already much-discussed (see the mail archives) issue. I was asking because I wanted to be referred to where I could find where these were discussed. I'm not going to wade through a search that I don't even have a hint on what to look for. - Jordan Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Excessive assembly code ?
On Thu, 5 Aug 1999, Arun Sharma wrote: I wonder if so much assembly code is really necessary for FreeBSD. One argument for minimal usage of assembly code is that it is easier to code non trivial algorithms in C. No, so much isn't really necessary. One such example is the scheduler. Since the decision about which process is going to run next is decided in assembly code, it is restricted to a relatively dumb algorithm of scanning the runqs and picking one. If the mechanism (i.e nuts and bolts of the context switch) is coded in assembly and the policy (which process to pick next) is done in C, the code would be much more maintainable, IMO. How do people feel about it here ? I feel that very low-level things need to be implemented in terms of in-line assembly in machdep files or headers, like inb/outb/etc. Coding much in assembly should be a very last resort. There really should not be any of those assembly files. They should all be C with whatever inline assembler is necessary or a call to the machine-dependent routines. Various things like, say, i586_bzero are assembly for good reason, but shouldn't be in assembly file format, IMHO. The scheduling code should DEFINITELY not be in assembly, but only have machine dependent calls for specific actions that need to be done manually in assembly. -Arun Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
On Fri, 6 Aug 1999, Daniel O'Connor wrote: On 06-Aug-99 Wes Peters wrote: Because it's wrong. If you don't believe me, buy a copy of the spec. Why should we waste valuable developer time trying to support mis-configured hardware? Since when has PC hardware followed the specs? Since it was made to work? The problem here is that this person, for some reason, is misconfiguring their system and expecting it to work as if it were configured properly. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum Brian Fundakowski Feldman _ __ ___ ___ ___ ___ [EMAIL PROTECTED] _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: IDE quirk in 3.2-STABLE kernel ?
Because it's wrong. If you don't believe me, buy a copy of the spec. Why should we waste valuable developer time trying to support mis-configured hardware? The box was shipped to me this way.. i'm no a hardware expert to know the IDE specs. As far as i know, it work for Windows (no flames) which i have been using for long. Suddenly if some one says that the PC is mis-configured... OK, i went to net and got this page (http://www.mit.edu/afs/sipb.mit.edu/project/linux/docs/faq/ATAPI-FAQ) there also they say it should be MASTER. Problem is not with me. The vendor didn't follow the specs. PC never followd specs i think ;) Some one please put this in an FAQ (if it is not already said) to avoid any future problem? thanks, -biju To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: m68k Support in FreeBSD (old thread)
On Mon, 19 Jul 1999, Jordan K. Hubbard wrote: website (http://www.freebsd.org/~green/FreeBSD-68k.txt). In about two weeks I'll have a spare Macintosh IIsi and would like to have a run at FreeBSD on it. So, to the point, where can I get it? :) I'd say that's a question for Grant Stockly, the person mentioned in green's web-cited message. It's certainly not part of FreeBSD and whether it ever will be is a matter still subject to debate. Prior to posting to -hackers, I had emailed him, I tried again after receiving this message and again, no response. (I used [EMAIL PROTECTED]) Is there a better way to contact this individual? Does anyone have a copy of the port? I've researched this guy a bit more, and I have to say I think it was a hoax. I really don't want to have to install NetBSD on this Mac :) Uh, MacBSD is actually pretty nice. Alan Briggs and team have done a really good job of keeping it up-to-date and functional. If I had to pick a platform to run NetBSD on for reference, the 68k Mac would feature high on the list (probably after the hp300, but that's another story). -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ [EMAIL PROTECTED] \\-- Joseph Merrick \\ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: IDE quirk in 3.2-STABLE kernel ?
OK, i went to net and got this page (http://www.mit.edu/afs/sipb.mit.edu/project/linux/docs/faq/AT API-FAQ) there also they say it should be MASTER. Problem is not with me. The vendor didn't follow the specs. PC never followd specs i think ;) Some one please put this in an FAQ (if it is not already said) to avoid any future problem? second thought.. I have not seen a PC with CD at any other configuration... Cant this config be supported? Many like me are not good in opening the box and fixing the problem like other hackers. (But don't say i should not use FBSD with CD ;). any thoughts? -biju To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: no getkerninfo() man page (docs/12220)
On Wed, Aug 04, 1999 at 03:59:00PM -0500, Jonathan Lemon wrote: getkerninfo() is depreciated, we use sysctl() instead. In fact, most of the information provided by getkerninfo() is implemented in terms of sysctl(). snip The route(4) manpage says: User processes can obtain information about the routing entry to a spe- cific destination by using a RTM_GET message, or by reading the /dev/kmem device, or by issuing a getkerninfo(2) system call. IMHO, the above sentence should probably be altered by replacing the first comma with a period, and throwing away the rest of it. Sounds fair enough. I'll allow 24 hours for objections, and then commit based on that, OK? N -- [intentional self-reference] can be easily accommodated using a blessed, non-self-referential dummy head-node whose own object destructor severs the links. -- Tom Christiansen in 37514...@cs.colorado.edu To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
When moving the CDROM to master though can cause problems. I had a Chaintech 5TDM board which refused to acknowledge a CDROM as secondary master. I thought it was a bug in FBSD since RH Linux could detect my CDROM as a secondary slave (only device on the controller). I never got a straight answer as to why it didnt work and why it shouldnt be changed or supported. I did get an answer from someone that said that it should work in 3.0+, I tried and it didnt work. *shrug* probably just my mobo and FBSD didnt like each other in this regard. regards, chris Vince Vielhaber wrote: On Wed, 4 Aug 1999, Biju Susmer wrote: hi, I tried yesterday to make the kernel understand my CD ROM drive.. but it refused. Here is the dmesg (of boot -v)... is my config wrong or i missed something? The drive is Acer 32X and connected as secondary slave. It is seen by Win98 and BIOS. Can someone help? You have the CD connected as the secondary slave and no secondary master. That's the problem. It's an illegal configuration as the IDE controller is actually on the drive itself. Move the jumper on the CD to master and it'll be recognized. Vince. -- == Vince Vielhaber -- KA8CSH email: v...@michvhf.com flame-mail: /dev/null # include std/disclaimers.h TEAM-OS2 Online Campground Directoryhttp://www.camping-usa.com Online Giftshop Superstorehttp://www.cloudninegifts.com == To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message -- Christopher Day E-Mail re...@tig.com.au Homepage http://www.geocities.com/TimesSquare/Lair/1218 when the rain/when the children reign/keep your conscience in the dark melt the statues in the park - Fall On Me, REM To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Results of investigating optimizing calloc()...
Peter Jeremy jere...@gsmx07.alcatel.com.au writes: Dag-Erling Smorgrav d...@flood.ping.uio.no wrote: The idea is to keep a chunk of zeroes on disk and DMA it into memory Have you looked at disk latencies recently? A modern CPU could zero- fill a decent fraction of its RAM in the time taken to fetch a page of zeroes from the platter. And if it was accessed frequently enough to keep the zeroed page in disk cache, you've just moved the bottleneck into that disk controller (and you've reduced the effective size of the disk's cache by a page). It still beats the hell out of invalidating your entire L1 and L2 caches. 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
Re: Results of investigating optimizing calloc()...
John-Mark Gurney wrote: Dag-Erling Smorgrav scribbled this message on Aug 4: Kelly Yancey kby...@alcnet.com writes: [...] Which reminds me - has anyone thought of using DMA for zeroing pages, to avoid cache invalidation? The idea is to keep a chunk of zeroes on disk and DMA it into memory instead of clearing pages manually. This assumes your disk supports DMA, of course. has anyone looked at using two dma channels tied together to do memory copies? I haven't studied the DMA specs, but from what I know of the dma on x86 machines is that you could tie two dma channels together one to feed the other, and this would allow you to copy memory w/o using the processor... w/ dma channels, we can just make a copy of the base zero page... Im not sure how much relevance this has, but many years ago I was writing video routines, I thought using software initiated DMA to copy pages of memory from one place to another would be a really cool and quick solution.
Re: Results of investigating optimizing calloc()...
Chris re...@tig.com.au writes: Anyways thats all I can think of. The only way I can see that using DMA to refresh pages as a faster method is if the DMA controller can do it quicker than the CPU which I doubt is likely, also it will only be useful if it can do 32-bit addresses. Grr.. *read what I f###ing wrote* The issue is not speed, because this is something we do in the background when there's nothing else to do. The issue is to avoid thrashing the cache. 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
Re: fetch: default to passive mode?
Chuck Youse cyo...@cybersites.com writes: I have a really strong urge to submit a PR to make fetch default to passive mode, instead of requiring a command-line switch ... fetch(1) honors FTP_PASSIVE_MODE. d...@des /usr/freebsd/current% lcvs log -r1.31 src/etc/login.conf RCS file: /home/ncvs/src/etc/login.conf,v Working file: src/etc/login.conf head: 1.32 branch: locks: strict access list: symbolic names: RELENG_3_2_PAO: 1.26.2.3.0.2 RELENG_3_2_PAO_BP: 1.26.2.3 RELENG_3_2_0_RELEASE: 1.26.2.3 RELENG_3_1_0_RELEASE: 1.26.2.1 RELENG_3: 1.26.0.2 RELENG_3_BP: 1.26 RELENG_2_2_8_RELEASE: 1.9.2.7 RELENG_3_0_0_RELEASE: 1.22 RELENG_2_2_7_RELEASE: 1.9.2.7 RELENG_2_2_6_RELEASE: 1.9.2.7 RELENG_2_2_5_RELEASE: 1.9.2.3 RELENG_2_2_2_RELEASE: 1.9 RELENG_2_2: 1.9.0.2 keyword substitution: kv total revisions: 43;selected revisions: 1 description: revision 1.31 date: 1999/05/28 11:07:16; author: jkh; state: Exp; lines: +2 -2 Set FTP_PASSIVE_MODE=YES by default in the default login class. = 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
Re: TCP stack hackers take a bow
Bill Fumerola writes: On Tue, 3 Aug 1999, Ted Faber wrote: http://www.sciencedaily.com/releases/1999/08/990802072727.htm The Duke release credits one Andrew Gallatin for a couple quotes. Not only FreeBSD in the news, but one of our own committers. Cool. http://www.dukenews.duke.edu/Research/GIGABIT.HTM Yes, my boss decided he wanted his 15 minutes of fame ;-) I tried hard to get FreeBSD a bigger mention than the rather poorly worded one that ended up coming out, but to little avail. After all, it is the BSD TCP stack that deserves the bulk of the credit; we were basically in the right place at the right time. It was very annoying that the person who wrote the local News Observer article seemed disappointed that we were not running linux probably because of that, didn't mention the OS at all in her article. Cheers, Drew -- Andrew Gallatin, Sr Systems Programmer http://www.cs.duke.edu/~gallatin Duke University Email: galla...@cs.duke.edu Department of Computer Science Phone: (919) 660-6590 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: TCP stack hackers take a bow
Bill Fumerola writes: On Tue, 3 Aug 1999, Ted Faber wrote: http://www.sciencedaily.com/releases/1999/08/990802072727.htm The Duke release credits one Andrew Gallatin for a couple quotes. Not only FreeBSD in the news, but one of our own committers. Cool. http://www.dukenews.duke.edu/Research/GIGABIT.HTM Yes, my boss decided he wanted his 15 minutes of fame ;-) I tried hard to get FreeBSD a bigger mention than the rather poorly worded one that ended up coming out, but to little avail. After all, it is the BSD TCP stack that deserves the bulk of the credit; we were basically in the right place at the right time. It was very annoying that the person who wrote the local News Observer article seemed disappointed that we were not running linux probably because of that, didn't mention the OS at all in her article. Yes - I noticed the conspicuous absence of any mention of BSD in the News Observer article. - Dave Rivers - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Multiple versions of FreeBSD on one HDD
Robert Nordier wrote: I assume that if I set the gemoetry in fdisk to be the BIOS figures, that I will lose the other half of the disk? Use 2096/255/63 in sysinstall. That worked! Here is what I did in the end: * set the BIOS disk type to Auto detect in LBA mode * booted 2.2.8 install diskette. Set the disk geometry in fdisk to 2096/255/63. * created three slices. The first two were both 3Gb, a bit smaller than I would have liked, but they both fit within the 1023 logical cylinder boundary. The third slice contained the remaining 10Gb+. About 5Mb of unused space was left at the end. * installed 2.2.8 into partition 1. * booted 2.2.8, and used fdisk to set the disk type to 6 * booted the 3.2 install disk. Checked the geometry settings were the same in fdisk, and set the second slice to be the active partition * installed 3.2 in the second slice * booted 3.2, and used its fdisk to set the partition type of the first slice back to 165 * booted a DOS diskette, and installed os-bs. The changing of the partition type was a necessary step; without this, the 3.2 install would still complain and refuse to make the root file system. Thanks for the help, Robert. Hopefully the summary above will be useful to others as well. g. -- Dr Graham WheelerE-mail: g...@cequrux.com Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security SpecialistsWWW:http://www.cequrux.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: TCP stack hackers take a bow
On Thu, 5 Aug 1999, Andrew Gallatin wrote: It was very annoying that the person who wrote the local News Observer article seemed disappointed that we were not running linux probably because of that, didn't mention the OS at all in her article. It's sad it has to be that way. I can't think of another product that is treated so poorly in the wake of another's success. What you broke a land speed record? Well, were you driving a Ford? No, well, we just won't mention that you were driving a Chevy. -- - bill fumerola - bi...@chc-chimes.com - BF1560 - computer horizons corp - - ph:(800) 252-2421 - bfume...@computerhorizons.com - bi...@freebsd.org - To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
login.conf restrictions for suid processes possible? (fwd)
No answer on -questions, and this is pretty urgent for me atm. Any help appreciated. Doug Greetings, :) I am working on some resource limit stuff and would like to be able to use login.conf to restrict the number of cgi processes that certain users can run. Unfortunately, the proprietary cgi product we use is owned by root and suid's to the user who owns the script that it is called to run. (This is not what I would call a good idea, but it's what I have to work with.) I've created a login class with the appropriate permissions, and if I put a test user in that class and test its limits with normal system processes (like ls, sleep, etc.) it follows all the rules. However when I start miva (proprietary cgi) processes for scripts owned by that user, it ignores the limits, presumably because the process starts its life as root. S, the question is, how can I do what I want to do, and if I can't do it with login.conf does anyone have any other suggestions? Specifically I need to restrict the amount of ram and the number of processes on a per user basis. I'm working on a -current system, but I don't think this issue bears directly on -current. Thanks for any help, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-questions 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: login.conf restrictions for suid processes possible? (fwd)
I am working on some resource limit stuff and would like to be able to use login.conf to restrict the number of cgi processes that certain users can run. Unfortunately, the proprietary cgi product we use is owned by root and suid's to the user who owns the script that it is called to run. (This is not what I would call a good idea, but it's what I have to work with.) I've created a login class with the appropriate permissions, and if I put a test user in that class and test its limits with normal system processes (like ls, sleep, etc.) it follows all the rules. However when I start miva (proprietary cgi) processes for scripts owned by that user, it ignores the limits, presumably because the process starts its life as root. S, the question is, how can I do what I want to do, and if I can't do it with login.conf does anyone have any other suggestions? Specifically I need to restrict the amount of ram and the number of processes on a per user basis. I'm working on a -current system, but I don't think this issue bears directly on -current. You need to pester the vendor to correctly switch limits when they switch UIDs. Alternatively, if this is unlikely _and_ the application is dynamically linked, you could produce a library containing patched set*id functions and force it into the app using LD_PRELOAD. -- \\ The mind's the standard \\ Mike Smith \\ of the man. \\ msm...@freebsd.org \\-- Joseph Merrick \\ msm...@cdrom.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: login.conf restrictions for suid processes possible? (fwd)
In article 199908051755.kaa13...@dingo.cdrom.com, Mike Smith m...@smith.net.au wrote: I am working on some resource limit stuff and would like to be able to use login.conf to restrict the number of cgi processes that certain users can run. Unfortunately, the proprietary cgi product we use is owned by root and suid's to the user who owns the script that it is called to run. (This is not what I would call a good idea, but it's what I have to work with.) [...] You need to pester the vendor to correctly switch limits when they switch UIDs. Alternatively, if this is unlikely _and_ the application is dynamically linked, you could produce a library containing patched set*id functions and force it into the app using LD_PRELOAD. N.B., LD_PRELOAD won't work if the program is setuid or setgid. I'm not 100% sure from the original post whether that's the case or not. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Memory Tuning
What type of memory do routing table entries use, and how can they be tuned? I've got a machine with 64M, and it will only allocate 10M to the routing table no matter what I set maxusers to. The full table is only 17M, so it should fit easily. Even if I have to change something in param.c...Im just at a loss as to what it needs. Dennis To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: login.conf restrictions for suid processes possible? (fwd)
On Thu, 5 Aug 1999, Mike Smith wrote: I am working on some resource limit stuff and would like to be able to use login.conf to restrict the number of cgi processes that certain users can run. Unfortunately, the proprietary cgi product we use is owned by root and suid's to the user who owns the script that it is called to run. (This is not what I would call a good idea, but it's what I have to work with.) I've created a login class with the appropriate permissions, and if I put a test user in that class and test its limits with normal system processes (like ls, sleep, etc.) it follows all the rules. However when I start miva (proprietary cgi) processes for scripts owned by that user, it ignores the limits, presumably because the process starts its life as root. S, the question is, how can I do what I want to do, and if I can't do it with login.conf does anyone have any other suggestions? Specifically I need to restrict the amount of ram and the number of processes on a per user basis. I'm working on a -current system, but I don't think this issue bears directly on -current. You need to pester the vendor to correctly switch limits when they switch UIDs. Alternatively, if this is unlikely _and_ the application is dynamically linked, you could produce a library containing patched set*id functions and force it into the app using LD_PRELOAD. Grrrfl. Ok, that's what I thought, but I do appreciate the confirmation. We have a pretty good relationship with the vendor so I'll take that route first. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: login.conf restrictions for suid processes possible? (fwd)
On Thu, 5 Aug 1999, John Polstra wrote: In article 199908051755.kaa13...@dingo.cdrom.com, Mike Smith m...@smith.net.au wrote: I am working on some resource limit stuff and would like to be able to use login.conf to restrict the number of cgi processes that certain users can run. Unfortunately, the proprietary cgi product we use is owned by root and suid's to the user who owns the script that it is called to run. (This is not what I would call a good idea, but it's what I have to work with.) [...] You need to pester the vendor to correctly switch limits when they switch UIDs. Alternatively, if this is unlikely _and_ the application is dynamically linked, you could produce a library containing patched set*id functions and force it into the app using LD_PRELOAD. N.B., LD_PRELOAD won't work if the program is setuid or setgid. I'm not 100% sure from the original post whether that's the case or not. Yes, the program is owned by root, has permissions -rwsr-xr-t and suid's to the user who owns the script it's called to run. I'm aware that the sticky bit is ignored on BSD for executables, but that's how it comes from the vendor so my boss doesn't want to mess with it. Thanks, Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: TCP stack hackers take a bow
On Thu, 5 Aug 1999, Bill Fumerola wrote: On Thu, 5 Aug 1999, Andrew Gallatin wrote: It was very annoying that the person who wrote the local News Observer article seemed disappointed that we were not running linux probably because of that, didn't mention the OS at all in her article. It's sad it has to be that way. I can't think of another product that is treated so poorly in the wake of another's success. Hmmm... OS/2 maybe? :) (Which is not to say that IBM didn't work very hard at shooting themselves in their collective feet at every opportunity.) But seriously folks, this kind of thing happens all the time in the computer business. The best way to handle it is to keep smiling and talk to the ones who will listen, and report accurately. The word is getting out slowly. Doug -- On account of being a democracy and run by the people, we are the only nation in the world that has to keep a government four years, no matter what it does. -- Will Rogers To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: bootloader....
From owner-freebsd-sm...@freebsd.org Fri Jul 30 10:45:10 1999 From: Nielsen, Roy S roy.s.niel...@intel.com To: 'freebsd-sm...@freebsd.org' freebsd-sm...@freebsd.org, 'freebsd-hackers@FreeBSD.org' freebsd-hackers@FreeBSD.ORG Subject: bootloader Date: Fri, 30 Jul 1999 10:44:57 -0700 I'm looking at booting(embedded devices) and I've been looking at lilo boot loader code and booteasy bootloader code... does anyone know of any documentation that anyone out there has done on this topic? -- more specifically without bios calls/support? I've seen the booteasy code at: ftp://ftp.freebsd.org/pub/FreeBSD/tools/srcs/bteasy/ is there a newer version? this code is supposed to be compiled with TASM/Borland C right? is there source that can be compiled with gnu tools? I'll take any and all suggestions :) Thanks, -roy To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-small in the body of the message FreeBSD 3.2-Release: /usr/src/sys/boot/i386/boot0 Note: this is one of a zillion of boot managers that do this. Note2: you only get 512 bytes loaded in from the MBR or 0 level boot. This is BARELY enough to use the BIOS calls. You use this to load the level 1 boot which is usually about 8K, and even it still uses the bios calls, due to the evil keyboard IO, disk IO remapping, etc. etc., etc. that the BIOS does. Patrick Powell Astart Technologies, papow...@astart.com9475 Chesapeake Drive, Suite D, Network and System San Diego, CA 92123 Consulting 619-874-6543 FAX 619-279-8424 LPRng - Print Spooler (http://www.astart.com) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: netstat broken for -N -M?
On Wed, Aug 04, 1999 at 05:21:49PM -0600, Warner Losh wrote: I'm seeing on a -stable system that netstat will always print values obtained from sysctl rather than from the core file specified. Can anybody confirm this? It doesn't seem like feature to me... Interesting - I got similar problems yesterday using netstat -m on a dump. I always showed me different mbuf usages on every run which is very unlikely for a dump. System is stable from the beginning of this week. -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de Usergroupi...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
possible syslogd bug?
I have a dedicated syslog machine runnign 3.2 and vanilla syslogd (started with -vv flags). After running for a few day the file would grow (this time file was ~40MB) and syslogd would stop writing to a file and go into a weird state. Here is the ktrace of hang syslogd before I did 'reboot' dlog# kdump 93 syslogd PSIG SIGALRM caught handler=0x804afb8 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL gettimeofday(0xefbfc84c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL setitimer(0,0xefbfc844,0xefbfc834) 93 syslogd RET setitimer 0 93 syslogd CALL sigreturn(0xefbfc880) 93 syslogd RET sigreturn JUSTRETURN 93 syslogd CALL poll(0xefbfc94c,0x1,0x9c40) 93 syslogd PSIG SIGALRM caught handler=0x804afb8 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL gettimeofday(0xefbfc84c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL setitimer(0,0xefbfc844,0xefbfc834) 93 syslogd RET setitimer 0 93 syslogd CALL sigreturn(0xefbfc880) 93 syslogd RET sigreturn JUSTRETURN 93 syslogd CALL poll(0xefbfc94c,0x1,0x9c40) 93 syslogd PSIG SIGTERM caught handler=0x804b178 mask=0x1 code=0x0 93 syslogd RET poll -1 errno 4 Interrupted system call 93 syslogd CALL sigprocmask(0x1,0x2001) 93 syslogd RET sigprocmask 16385/0x4001 93 syslogd CALL gettimeofday(0xefbfc08c,0) 93 syslogd RET gettimeofday 0 93 syslogd CALL writev(0x12,0xefbfc04c,0x7) 93 syslogd GIO fd 18 wrote 64 bytes Aug 3 21:52:25 syslog.err dlog syslogd: exiting on signal 15 93 syslogd RET writev 64/0x40 93 syslogd CALL writev(0x1d,0xefbfc04c,0x7) 93 syslogd GIO fd 29 wrote 64 bytes Aug 3 21:52:25 syslog.err dlog syslogd: exiting on signal 15 93 syslogd RET writev 64/0x40 93 syslogd CALL sigprocmask(0x3,0x4001) 93 syslogd RET sigprocmask 24577/0x6001 93 syslogd CALL unlink(0x804c9e5) 93 syslogd NAMI /var/run/log 93 syslogd RET unlink 0 93 syslogd CALL exit(0x1) System also shows syslogd is in poll() state when it hangs .. I did not see anything wrong with syslogd.c when I looked. The file is now at 62MB, I see if I can debug this further next time syslogd hangs. -- yan P.S. -- Yes, *.* is going into that file ;) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
BSD XFS Port BSD VFS Rewrite
I am currently conducting a thorough study of the VFS subsystem in preparation for an all-out effort to port SGI's XFS filesystem to FreeBSD 4.x at such time as SGI gives up the code. Matt Dillon has written in hackers- that the VFS subsystem is presently not well understood by any of the active kernel code contributers and that it will be rewritten later this year. This is obviously of great concern to me in this port. I greatly appreciate all assistance in answering the following questions: 1) What are the perceived problems with the current VFS? 2) What options are available to us as remedies? 3) To what extent will existing FS code require revision in order to be useful after the rewrite? 4) Will Chapters 6,7,8 9 of The Design and Implementation of the 4.4BSD Operating System still pertain after the rewrite? 5) How important are questions 3 4 in the design of the new VFS? I believe that the VFS is conceptually sound and that the existing semantics should be strictly retained in the new code. Any new functionality should be added in the form of entirely new kernel routines and system calls, or possibly by such means as converting the existing routines to the vararg format etc. Does anyone know when SGI will release XFS? Matthew Alton Computer Services - UNIX Systems Administration (314)632-6644 matthew.al...@anheuser-busch.com al...@plantnet.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: TCP stack hackers take a bow
%Unmodified FreeBSD TCP at 1Gb/s. % %http://www.sciencedaily.com/releases/1999/08/990802072727.htm That is so very cool. There is a separate war going on optimizing bandwidth, latency, and QoS for IIOP, i.e. CORBA's usual protocol. Against all of the heavyweights, RTOS's etc. etc., linux is looking very good. Surprisingly good. Thus... Cheers, Russell To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
FreeMWare for FreeBSD??
Original Message Subject: FreeMWare for FreeBSD?? Date: Thu, 05 Aug 1999 12:54:25 -0600 From: Darren WIebe dkwi...@hagenhomes.com Newsgroups: comp.unix.bsd.freebsd.misc Hello All: I have been communicating with the person behind the Freemware project and he stressed that the software would not only be for Linux. For a start it will probably run on Linux, they had to chose a starting point. However, anybody interested in working on the necessary patches to make it run on FreeBSD, or any other O.S. for that matter, would be strongly encouraged to do so. It is there goal to have it run on many O.S. He also stressed that it is most definitely NOT just a Linux Project. Maybe the rest of you knew that this was not going to be only for Linux, but I did not. For those of you that did not know anything about this, it is a project to come up with free software that will run multiple operating systems simultaneously. From the amount of questions there have been on whether we can run VMWare, I think that there is a demand for the capability. Can we get some help for the project. If you have questions you can look at the web site at www.freemware.org. Thanks in Advance, Darren Wiebe dkwi...@hagenhomes.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
more crashes and fixes (linux/svr4/ibcs2)
Thanks to our Peter Holm's stress testing suite, I found a pretty bad
bug in all current emulation (*) code. They all share a common base, and
the problem is in the pathname translation code.
What it amounts to is the inherent assumption that all passed in paths
are valid addresses. This is not true, and the problem occurs when the
stackgap memory (used when we pass the path to good ol' namei/NDINIT)
does not contain valid data. This can happen very easily:
1. A bad address is passed to the kernel with a syscall, i.e.
linux_uselib().
2. Linux_uselib() calls a macro which calls linux_emul_find().
3. Linux_emul_find() notices that the address is invalid
(via return of EFAULT from copyinstr()) and returns that.
4. The code ignores the error and continues on its merry way,
assuming that the stackgap contains valid data, but it
will only get to problems. namei() will crash when it
gets a page fault trying to copyinstr() from UIO_SYSSPACE.
Here's my fix:
--- src/sys/i386/linux/linux_util.h.origThu Aug 5 18:32:02 1999
+++ src/sys/i386/linux/linux_util.h Thu Aug 5 19:03:27 1999
@@ -83,10 +83,17 @@
int linux_emul_find __P((struct proc *, caddr_t *, const char *, char *,
char **, int));
-#define CHECKALTEXIST(p, sgp, path) \
-linux_emul_find(p, sgp, linux_emul_path, path, (path), 0)
+#define CHECKALT(p, sgp, path, i) \
+ do {\
+ int _error; \
+ \
+ _error = linux_emul_find(p, sgp, linux_emul_path, path, \
+ path, i); \
+ if (_error) \
+ return (_error);\
+ } while (0)
-#define CHECKALTCREAT(p, sgp, path) \
-linux_emul_find(p, sgp, linux_emul_path, path, (path), 1)
+#define CHECKALTEXIST(p, sgp, path) CHECKALT(p, sgp, path, 0)
+#define CHECKALTCREAT(p, sgp, path) CHECKALT(p, sgp, path, 1)
#endif /* !_LINUX_UTIL_H_ */
Either this or a similar fix will be necessary for svr4, ibcs2, and linux.
(*) I said emulation because we are emulating the ABI for another OS.
Therefore, linux.ko, svr4.ko, and ibcs2*.ko are all emulators.
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: How the `struct linker_set' is used in building an ELF kernel?
In article 87n1wag14v@joelu.m8.ntu.edu.tw, Joe Jih-Shien Lu b84...@ee.ntu.edu.tw wrote: I started studying 3.2-stable kernel source for days. There are some questions I cannot figure out in an ordinary C programmer's point of view: * In cninit(), it references a global variable `cons_set' of the type `struct linker_set,' but I don't see its definition in any of the source files except the setdef0.c generated by /usr/bin/gensetdefs. It is defined by the .long asm psuedo-op, and seems to have the size of 4 bytes. However, in /sys/i386/i386/cons.h, it is declared as of the type `struct linker_set' which is 8-byte long. This inconsistency confused me. * Similar problem is encountered when I'm poking around the system initializing for-loop in main(). sysinit_set, declared as struct linker_set, is referenced, but I can't get into the way how this variable is initialized. I guess it is the linker who did all the magic, since the comment in /sys/sys/linker_set.h mentioned about it. After studying the linker script (/sys/i386/conf/kernel.script) and ld.info, though, I still don't have any idea about the details behind the scene. Linker sets are basically arrays of pointers that are constructed by the linker using values that can come from many object files. The first word contains the number of elements (pointers) in the set. Then come the pointers themselves. Finally, a NULL pointer appears at the end of the set. The old a.out linker supported linker sets directly, and did all the bookkeeping necessary to keep track of the set sizes and so forth. The ELF linker does not directly support linker sets. However, it does support an arbitrary number of independent sections. Using that along with a little help from gensetdefs, we can get a.out-style linker sets using the ELF tools. setdef0.o must appear first on the linker command line. It contributes the leading count word to each set. Then come the normal object files, which may contribute pointers to various sets. These are just appended to special sections, one per linker set. Finally comes setdef1.o, which emits the terminating NULL pointers. I notice that gensetdefs looks for the sections by the `.set.'-prefixed name in all the ELF kernel object files, and produces the setdef[12].c accordingly. Does the `.set.'-prefixed section name have any special meaning in an ELF object file? No, it is just a convention we use for naming the sections that contain linker sets. gensetdefs knows this convention, and so do the macros in sys/linker_set.h. The compiler, assembler, and linker aren't aware of anything special about the names. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
Peter Jeremy wrote: I apologize if I gave anyone the impression that you couldn't build statically linked executables with libpam. Sorry I was so prickly about it. I recall having a similar static-vs-dynamic discussion with you a couple of years ago. Yow, your memory is better than mine. Premature senility is a sad, sad thing. :-} My position was (and still is) that for most purposes dynamic linking is a definite advantage, but we should continue to permit static linking for applications that want it (which Sun doesn't). I generally agree, except I feel that when there are cases where we can do useful things which rely on dynamic linking, we shouldn't let static linking hold us back. Plenty of people disagree with me, though. John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
Chris wrote: When moving the CDROM to master though can cause problems. I had a Chaintech 5TDM board which refused to acknowledge a CDROM as secondary master. I thought it was a bug in FBSD since RH Linux could detect my CDROM as a secondary slave (only device on the controller). I never got a straight answer as to why it didnt work and why it shouldnt be changed or supported. I did get an answer from someone that said that it should work in 3.0+, I tried and it didnt work. *shrug* probably just my mobo and FBSD didnt like each other in this regard. Regardless, you have to have 1 master and 0 or 1 slaves one every IDE controller. You can't run a controller with just a slave. -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: fetch: default to passive mode?
On 05-Aug-99 Dag-Erling Smorgrav wrote: Chuck Youse cyo...@cybersites.com writes: I have a really strong urge to submit a PR to make fetch default to passive mode, instead of requiring a command-line switch ... fetch(1) honors FTP_PASSIVE_MODE. Speaking of fetch features.. Are there any plans to make fetch use a http proxy for ftp requests like ftp does? At the moment I usually do 'make FETCH_CMD=ftp' when making ports since it honours ftp_proxy (like wget, netscape and lynx) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgpaOS8s9MfwZ.pgp Description: PGP signature
Re: more crashes and fixes (linux/svr4/ibcs2)
On Thu, 5 Aug 1999, Brian F. Feldman wrote:
Correction:
--- src/sys/i386/linux/linux_util.h.orig Thu Aug 5 18:32:02 1999
+++ src/sys/i386/linux/linux_util.h Thu Aug 5 19:03:27 1999
@@ -83,10 +83,17 @@
int linux_emul_find __P((struct proc *, caddr_t *, const char *, char *,
char **, int));
-#define CHECKALTEXIST(p, sgp, path) \
-linux_emul_find(p, sgp, linux_emul_path, path, (path), 0)
+#define CHECKALT(p, sgp, path, i)\
+ do {\
+ int _error; \
+ \
+ _error = linux_emul_find(p, sgp, linux_emul_path, path, \
+ path, i); \
+ if (_error) \
This should only be
if (_error == EFAULT)
+ return (_error);\
+ } while (0)
-#define CHECKALTCREAT(p, sgp, path) \
-linux_emul_find(p, sgp, linux_emul_path, path, (path), 1)
+#define CHECKALTEXIST(p, sgp, path) CHECKALT(p, sgp, path, 0)
+#define CHECKALTCREAT(p, sgp, path) CHECKALT(p, sgp, path, 1)
#endif /* !_LINUX_UTIL_H_ */
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: Adding disks -the pain. Also vinum
On Tuesday, 3 August 1999 at 23:20:45 +0200, Bernd Walter wrote: On Tue, Aug 03, 1999 at 03:59:46PM +0930, Greg Lehey wrote: On Tuesday, 3 August 1999 at 8:12:17 +0200, Bernd Walter wrote: For UFS/FFS there is nothing worth seting the stripesize to low. It is generally slower to acces 32k on different HDDs than to acces 64k on one HDD. It is always slower where the positioning time is greater than the transfer time for 32 kB. On modern disks, 32 kB transfer in about 300 µs. The average rotational latency of a disk running at 10,800 rpm is 2.8 ms, and even with spindle synchronization there's no way to avoid rotational latency under these circumstances. It shouldn't be the latency, because with spindlesync they are the same on both disks if the transfer is requested exactly the same time what is of course idealized.. Spindle sync ensures that the same sectors on different disks are under the heads at the same time. When you perform a stripe transfer, you're not accessing the same sectors, you're accessing different sectors. There's no way to avoid rotational latency under these circumstances. The point is that you have more then a single transfer. With small transfers spindle sync is able to winback some of the performance you have lost with a to small stripe size. No, this isn't correct, unless you're running 512 byte stripes. In this case, a single-stripe transfer of, say, 8 kB with the disks above would take about 7 ms total latency (same as with a single disk), but the transfer would take less time--5 µs instead of 80 µs. You'd need 16 disks, and you'd tie them all up for 7 ms. And this doesn't consider the times of SCSI command setup and such. Basically, this is not the way to go if you have multiple clients for your storage. Look at http://www.lemis.com/vinum/problems.html and http://www.lemis.com/vinum/Performance-issues.html and for more details. Spindle Sycronisation won't bring you that much on modern HDDs - I tried it using 5 Seagate Elite 2.9G (5,25 Full-Height). It should be useful for RAID-3 and streaming video. I case of large transfers it will make sense - but FFS is unable to set up big enough requests. No, this is a case where you're only using one client, so my argumentation above doesn't apply (since you're reading sequentially, so latency is no longer an issue). 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
Re: NSS Project
On Thu, 5 Aug 1999, John Polstra wrote: My position was (and still is) that for most purposes dynamic linking is a definite advantage, but we should continue to permit static linking for applications that want it (which Sun doesn't). I generally agree, except I feel that when there are cases where we can do useful things which rely on dynamic linking, we shouldn't let static linking hold us back. Plenty of people disagree with me, though. Mind pointing me to the technical reason why (I'm sure you've explained it before) we can't use the dl* calls in any way without linking against ld-elf.so.1? I mean, have them in libc, for instance... One option I don't think anyone's brought up: why don't we _just_ have ld-elf.so.1 in the root, but not libraries? That way, we don't bloat root excessively, but we can let people depend on being able to build -static/-Bstatic binaries that make everything static except the rtld? And modify gcc/ld to have static link with the rtld, so we have the benefit of those calls, can have static binaries still, and be able to depend on having an rtld (even for single-user mode.) John --- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeMWare for FreeBSD??
What is FreeMWare? It sounds like a free / Open source implementation of the VMware virtual machine. Do you have an URL that I could look up? This sounds interesting! Donald Burr db...@powered-by.ac WEB: http://www.Powered-By.AC/ PO Box 91212, Santa Barbara, CA 93190-1212 Tel:(805)957-9666 FAX:(800)492-5954 Member and software developer with The FreBSD Project - http://www.FreeBSD.ORG/ *** FreeBSD *** A FREE, 32 Bit UNIX OS for PC's -- The Power to Serve! On Thu, 5 Aug 1999, Donn Miller wrote: I have been communicating with the person behind the Freemware project and he stressed that the software would not only be for Linux. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeMWare for FreeBSD??
On Thu, Aug 05, 1999 at 06:42:39PM -0700, Donald Burr wrote: What is FreeMWare? It sounds like a free / Open source implementation of the VMware virtual machine. Do you have an URL that I could look up? This sounds interesting! It's at www.freemware.org. I should say, though, that it's very much pre-alpha at the moment; no downloadables yet, but they do have a mailing list you can join. -lee -- ++ | Lee Cremeans -- Manassas, VA, USA (WakkyMouse on WTnet) | | lcreme...@erols.com | http://wakky.dyndns.org/~lee | To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeMWare for FreeBSD??
Thanks. I wasn't expecting any available software at the moment, I just wanted a URL so that I could watch over this project and keep track of it. Definitely something Im interested in. Donald Burr db...@powered-by.ac WEB: http://www.Powered-By.AC/ PO Box 91212, Santa Barbara, CA 93190-1212 Tel:(805)957-9666 FAX:(800)492-5954 Member and software developer with The FreBSD Project - http://www.FreeBSD.ORG/ *** FreeBSD *** A FREE, 32 Bit UNIX OS for PC's -- The Power to Serve! On Thu, 5 Aug 1999, Lee Cremeans wrote: It's at www.freemware.org. I should say, though, that it's very much pre-alpha at the moment; no downloadables yet, but they do have a mailing list you can join. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: IDE quirk in 3.2-STABLE kernel ?
Regardless, you have to have 1 master and 0 or 1 slaves one every IDE controller. You can't run a controller with just a slave. I dont think it should be a problem.. Since other OSs can work with this configuration without any problem, why FBSD should refuse this configuration? When i was using 2.2.7-stable, FBSD used to recognize my CDROM *sometimes* as slave, not always. -biju To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: m68k Support in FreeBSD (old thread)
On Mon, 19 Jul 1999, Jordan K. Hubbard wrote: website (http://www.freebsd.org/~green/FreeBSD-68k.txt). In about two weeks I'll have a spare Macintosh IIsi and would like to have a run at FreeBSD on it. So, to the point, where can I get it? :) I'd say that's a question for Grant Stockly, the person mentioned in green's web-cited message. It's certainly not part of FreeBSD and whether it ever will be is a matter still subject to debate. Prior to posting to -hackers, I had emailed him, I tried again after receiving this message and again, no response. (I used gus...@alaska.net) Is there a better way to contact this individual? Does anyone have a copy of the port? I really don't want to have to install NetBSD on this Mac :) Jamie To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
cvs
Can someone tell me how to make a cvs archive work for users that aren't the owner of the archive, the way that it works on Freefall? I *am* doing this for a cvsup maintained FreeBSD archive, but not freefall, and I need to get one user, who is not the archive owner, to be able to be able to do checkouts and diffs (no source changes, but it needs to be able to lock directories for checkouts). Thanks. +--- Chuck Robey | Interests include any kind of voice or data chu...@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic and jaunt, both FreeBSD-current. (301) 220-2114 | +--- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
In article pine.bsf.4.10.9908052127030.86114-100...@janus.syracuse.net, Brian F. Feldman gr...@freebsd.org wrote: Mind pointing me to the technical reason why (I'm sure you've explained it before) we can't use the dl* calls in any way without linking against ld-elf.so.1? I mean, have them in libc, for instance... The versions in libc are just stubs. Take a look at src/lib/libc/gen/dlfcn.c. The implementations are in the dynamic linker. One option I don't think anyone's brought up: why don't we _just_ have ld-elf.so.1 in the root, but not libraries? That way, we don't bloat root excessively, but we can let people depend on being able to build -static/-Bstatic binaries that make everything static except the rtld? And modify gcc/ld to have static link with the rtld, so we have the benefit of those calls, can have static binaries still, and be able to depend on having an rtld (even for single-user mode.) I think you have some misconceptions about how it all fits together. Executables aren't linked with the dynamic linker. It's a separate shared object that is loaded directly by the kernel. It gets control before the main executable gets control. Look at src/sys/kern/imgact_elf.c and at the dynamic linker. Also, programs that are linked (at ld time) with dynamic libraries are different from programs that are linked with static libraries. I.e., ld does very different things in the two cases. You can't take a statically-linked program and suddenly decide to treat it as dynamically-linked at runtime. It's too late at that point. Finally, shared libraries aren't really libraries at all in the traditional sense. They're monolithic whereas traditional archive libraries are made up of separate object files which are subsetted by the linker. To really understand the issues I think it's necessary to read through the dynamic linker sources and understand what it's doing. There used to be books that described how it all worked (Prentice-Hall System V Application Binary Interface), but as far as I know they're out of print now. John -- John Polstra j...@polstra.com John D. Polstra Co., Inc.Seattle, Washington USA No matter how cynical I get, I just can't keep up.-- Nora Ephron To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: NSS Project
On Thu, 5 Aug 1999, John Polstra wrote:
In article pine.bsf.4.10.9908052127030.86114-100...@janus.syracuse.net,
Brian F. Feldman gr...@freebsd.org wrote:
Mind pointing me to the technical reason why (I'm sure you've explained
it before) we can't use the dl* calls in any way without linking
against ld-elf.so.1? I mean, have them in libc, for instance...
The versions in libc are just stubs. Take a look at
src/lib/libc/gen/dlfcn.c. The implementations are in the dynamic
linker.
Yes. I said have them as in we could, not we do have them in libc...
One option I don't think anyone's brought up: why don't we _just_
have ld-elf.so.1 in the root, but not libraries? That way, we
don't bloat root excessively, but we can let people depend on
being able to build -static/-Bstatic binaries that make everything
static except the rtld? And modify gcc/ld to have static link with
the rtld, so we have the benefit of those calls, can have static
binaries still, and be able to depend on having an rtld (even for
single-user mode.)
I think you have some misconceptions about how it all fits together.
Executables aren't linked with the dynamic linker. It's a
separate shared object that is loaded directly by the kernel. It
gets control before the main executable gets control. Look at
src/sys/kern/imgact_elf.c and at the dynamic linker.
I suppose I do have some misconceptions. I'll look at the FreeBSD ELF
image activator. I know how ld-elf gets control first, and calls .init
things, etc. But:
{/usr/src/contrib/egcs}$ grep -R ld-elf .
./gcc/config/alpha/freebsd.h: %{!dynamic-linker:-dynamic-linker
/usr/libexec/ld-elf.so.1}} \
./gcc/config/i386/freebsd.h:%{!dynamic-linker: -dynamic-linker
/usr/libexec/ld-elf.so.1}} \
./gcc/config/i386/freebsd-elf.h:%{!dynamic-linker:-dynamic-linker
/usr/libexec/ld-elf.so.1}} \
What should that tell me exactly?
Also, programs that are linked (at ld time) with dynamic libraries
are different from programs that are linked with static libraries.
I.e., ld does very different things in the two cases. You can't
take a statically-linked program and suddenly decide to treat it as
dynamically-linked at runtime. It's too late at that point.
Of course, but you can have a pseudo-static binary, one that only
needs ld-elf.so.1 but not libc, etc.
Finally, shared libraries aren't really libraries at all in the
traditional sense. They're monolithic whereas traditional archive
libraries are made up of separate object files which are subsetted by
the linker.
Mm-hmm. ld -Bshareable as opposed to ar rc.
To really understand the issues I think it's necessary to read through
the dynamic linker sources and understand what it's doing. There used
to be books that described how it all worked (Prentice-Hall System V
Application Binary Interface), but as far as I know they're out of
print now.
I just think we're not seeing eye to eye.
John
--
John Polstra j...@polstra.com
John D. Polstra Co., Inc.Seattle, Washington USA
No matter how cynical I get, I just can't keep up.-- Nora Ephron
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Brian Fundakowski Feldman _ __ ___ ___ ___ ___
gr...@freebsd.org _ __ ___ | _ ) __| \
FreeBSD: The Power to Serve!_ __ | _ \._ \ |) |
http://www.FreeBSD.org/ _ |___/___/___/
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Excessive assembly code ?
Taking a quick look at /usr/src/sys/i386: find . -name *.s | xargs wc -l 44 ./svr4/svr4_locore.s 216 ./apm/apm_setup.s 24 ./linux/linux_locore.s 461 ./isa/apic_ipl.s 1057 ./isa/apic_vector.s 168 ./isa/icu_ipl.s 224 ./isa/icu_vector.s 387 ./isa/ipl.s 113 ./isa/vector.s 59 ./i386/bioscall.s 340 ./i386/exception.s 192 ./i386/globals.s 1000 ./i386/locore.s 319 ./i386/mpboot.s 555 ./i386/mplock.s 310 ./i386/simplelock.s 1636 ./i386/support.s 833 ./i386/swtch.s 190 ./i386/vm86bios.s 8128 total I wonder if so much assembly code is really necessary for FreeBSD. One argument for minimal usage of assembly code is that it is easier to code non trivial algorithms in C. One such example is the scheduler. Since the decision about which process is going to run next is decided in assembly code, it is restricted to a relatively dumb algorithm of scanning the runqs and picking one. If the mechanism (i.e nuts and bolts of the context switch) is coded in assembly and the policy (which process to pick next) is done in C, the code would be much more maintainable, IMO. How do people feel about it here ? -Arun To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Adding disks -the pain. Also vinum
On Fri, Aug 06, 1999 at 10:53:54AM +0930, Greg Lehey wrote: On Tuesday, 3 August 1999 at 23:20:45 +0200, Bernd Walter wrote: On Tue, Aug 03, 1999 at 03:59:46PM +0930, Greg Lehey wrote: On Tuesday, 3 August 1999 at 8:12:17 +0200, Bernd Walter wrote: For UFS/FFS there is nothing worth seting the stripesize to low. It is generally slower to acces 32k on different HDDs than to acces 64k on one HDD. It is always slower where the positioning time is greater than the transfer time for 32 kB. On modern disks, 32 kB transfer in about 300 µs. The average rotational latency of a disk running at 10,800 rpm is 2.8 ms, and even with spindle synchronization there's no way to avoid rotational latency under these circumstances. It shouldn't be the latency, because with spindlesync they are the same on both disks if the transfer is requested exactly the same time what is of course idealized.. Spindle sync ensures that the same sectors on different disks are under the heads at the same time. When you perform a stripe transfer, you're not accessing the same sectors, you're accessing different sectors. There's no way to avoid rotational latency under these circumstances. We are talking about the same point with the sme results. I agree you will only access the same sectors in some special cases. Lets say 2 Striped disks with 512 Byte stripes and FSS with 1k Frags. The point is that you have more then a single transfer. With small transfers spindle sync is able to winback some of the performance you have lost with a to small stripe size. No, this isn't correct, unless you're running 512 byte stripes. In That's what I meant with a 'to small stripe size' this case, a single-stripe transfer of, say, 8 kB with the disks above would take about 7 ms total latency (same as with a single disk), but the transfer would take less time--5 µs instead of 80 µs. You'd need 16 disks, and you'd tie them all up for 7 ms. And this doesn't consider the times of SCSI command setup and such. In the rare case you need max bandwith for only one Aplication and one stream I like to hear that all drives are tied up in the job. Basically, this is not the way to go if you have multiple clients for your storage. Look at http://www.lemis.com/vinum/problems.html and http://www.lemis.com/vinum/Performance-issues.html and for more details. Spindle Sycronisation won't bring you that much on modern HDDs - I tried it using 5 Seagate Elite 2.9G (5,25 Full-Height). It should be useful for RAID-3 and streaming video. I case of large transfers it will make sense - but FFS is unable to set up big enough requests. No, this is a case where you're only using one client, so my argumentation above doesn't apply (since you're reading sequentially, so latency is no longer an issue). I don't know what bandwith streaming video needs, but If you need sdditional bandwith of all used disks the first thing to do is linearising access to the disks. Multifileaccess often breaks linearisation. All what I trid to say is that it is hopeless to expect much more bandwith than a single disk in single process access. As an example: Yesterday I was asked if 6 old striped disks would be faster for cvsup than one of his modern disks because it sometime needs more than one telephone unit. The answer is no. cvsupd (if run regulary) spends most of its time sending The directory content of the destination. Usually there are no other programms accessng any disks at the same time, so you can benefit only a very small bit from additional drives. Maybe the additional block cache on the drives and for updating atime. Beleave it or not multiple files are accessed in servers and maybe under some windomanagers, but on many home and desktop machines it happens only rarely. I personaly use as an example 7 200M IBM Disks striped to one volume (They all have LEDs :). The only way for to utilize nearly all in a sensefull way is writing with softupdates enabled. -- B.Walter COSMO-Project http://www.cosmo-project.de ti...@cicely.de Usergroupi...@cosmo-project.de To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: fetch: default to passive mode?
Daniel O'Connor scribbled this message on Aug 6: On 05-Aug-99 Dag-Erling Smorgrav wrote: Chuck Youse cyo...@cybersites.com writes: I have a really strong urge to submit a PR to make fetch default to passive mode, instead of requiring a command-line switch ... fetch(1) honors FTP_PASSIVE_MODE. Speaking of fetch features.. Are there any plans to make fetch use a http proxy for ftp requests like ftp does? At the moment I usually do 'make FETCH_CMD=ftp' when making ports since it honours ftp_proxy (like wget, netscape and lynx) hmmm... are you sure it doesn't? metriclient-1,ttype,/tmp,509$echo $HTTP_PROXY localhost:3128 metriclient-1,ttype,/tmp,507$fetch ftp://ftp.cdrom.com/config.txt Receiving config.txt: 3 Kbytes 3575 bytes transfered in 0.7 seconds (5.15 Kbytes/s) metriclient-1,ttype,/tmp,501#tail squid.access 933914913.491 3750 127.0.0.1 TCP_MISS/200 3816 GET ftp://ftp.cdrom.com/config.txt - DIRECT/ftp.cdrom.com text/plain sure looks like it uses the http proxy, and this is on 3.0-R... -- John-Mark Gurney Voice: +1 541 684 8449 Cu Networking P.O. Box 5693, 97405 The soul contains in itself the event that shall presently befall it. The event is only the actualizing of its thought. -- Ralph Waldo Emerson To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: fetch: default to passive mode?
On 06-Aug-99 John-Mark Gurney wrote: metriclient-1,ttype,/tmp,501#tail squid.access 933914913.491 3750 127.0.0.1 TCP_MISS/200 3816 GET ftp://ftp.cdrom.com/config.txt - DIRECT/ftp.cdrom.com text/plain sure looks like it uses the http proxy, and this is on 3.0-R... Hmm.. sneaky :) I should have read the man page more thoroughly it would seem. --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgpAVH2wQu6Jt.pgp Description: PGP signature
Re: NSS Project
Mm-hmm. ld -Bshareable as opposed to ar rc. This demonstrates a superficial understanding of the process, nothing more. I just think we're not seeing eye to eye. I'd be more inclined to say that John simply understands this where you don't. Go study up, then come back and engage the poor guy in debate if you genuinely feel you have a solution to offer to this already already much-discussed (see the mail archives) issue. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: m68k Support in FreeBSD (old thread)
On Thu, 5 Aug 1999, James Howard wrote:
Prior to posting to -hackers, I had emailed him, I tried again after
receiving this message and again, no response. (I used gus...@alaska.net)
Is there a better way to contact this individual? Does anyone have a copy
of the port?
I really don't want to have to install NetBSD on this Mac :)
Worse things could happen :^)
I haven't heard from him either (since I sent out my first inquiry July
19th). But all things considered it should be a bit easier to port
NetBSD/mac68k to FreeBSD than it would with the Alpha bits, considering
that you can setup a m68k-aout cross compiler pretty easily ('course easy
is a relative term).
FWIW, NetBSD works quite well on mac68k, but the biggest problem so far is
the lack of virtual consoles (dt is awful).
- alex
You better believe that marijuana can cause castration. Just suppose your
girlfriend gets the munchies!
To Unsubscribe: send mail to majord...@freebsd.org
with unsubscribe freebsd-hackers in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
Biju Susmer wrote: Regardless, you have to have 1 master and 0 or 1 slaves one every IDE controller. You can't run a controller with just a slave. I dont think it should be a problem.. Since other OSs can work with this configuration without any problem, why FBSD should refuse this configuration? When i was using 2.2.7-stable, FBSD used to recognize my CDROM *sometimes* as slave, not always. Because it's wrong. If you don't believe me, buy a copy of the spec. Why should we waste valuable developer time trying to support mis-configured hardware? -- Where am I, and what am I doing in this handbasket? Wes Peters Softweyr LLC http://softweyr.com/ w...@softweyr.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: IDE quirk in 3.2-STABLE kernel ?
On 06-Aug-99 Wes Peters wrote: Because it's wrong. If you don't believe me, buy a copy of the spec. Why should we waste valuable developer time trying to support mis-configured hardware? Since when has PC hardware followed the specs? --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum pgp7jl8N8NMAN.pgp Description: PGP signature
Re: NSS Project
On Thu, 5 Aug 1999, Jordan K. Hubbard wrote: Mm-hmm. ld -Bshareable as opposed to ar rc. This demonstrates a superficial understanding of the process, nothing more. I know exactly how an ar archive is made of all the non-PIC .o files and a ranlib works. I know what happens when ld puts together position- independent-code (which is position-independent because it uses the GOT) and generates a shared library. I know how GCC only includes the .o files from an ar library archive which it needs and nothing more. I know that the dl* functions in libc itself are just stubs. All I don't know is why we can't load ld-elf.so.1 for static executables as well as dynamic ones. I just think we're not seeing eye to eye. I'd be more inclined to say that John simply understands this where you don't. Go study up, then come back and engage the poor guy in debate if you genuinely feel you have a solution to offer to this already already much-discussed (see the mail archives) issue. I was asking because I wanted to be referred to where I could find where these were discussed. I'm not going to wade through a search that I don't even have a hint on what to look for. - Jordan Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Excessive assembly code ?
On Thu, 5 Aug 1999, Arun Sharma wrote: I wonder if so much assembly code is really necessary for FreeBSD. One argument for minimal usage of assembly code is that it is easier to code non trivial algorithms in C. No, so much isn't really necessary. One such example is the scheduler. Since the decision about which process is going to run next is decided in assembly code, it is restricted to a relatively dumb algorithm of scanning the runqs and picking one. If the mechanism (i.e nuts and bolts of the context switch) is coded in assembly and the policy (which process to pick next) is done in C, the code would be much more maintainable, IMO. How do people feel about it here ? I feel that very low-level things need to be implemented in terms of in-line assembly in machdep files or headers, like inb/outb/etc. Coding much in assembly should be a very last resort. There really should not be any of those assembly files. They should all be C with whatever inline assembler is necessary or a call to the machine-dependent routines. Various things like, say, i586_bzero are assembly for good reason, but shouldn't be in assembly file format, IMHO. The scheduling code should DEFINITELY not be in assembly, but only have machine dependent calls for specific actions that need to be done manually in assembly. -Arun Brian Fundakowski Feldman _ __ ___ ___ ___ ___ gr...@freebsd.org _ __ ___ | _ ) __| \ FreeBSD: The Power to Serve!_ __ | _ \._ \ |) | http://www.FreeBSD.org/ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
