Re: USFS (User Space File System)
: :Portal FS did give me a couple of starting points.. It looks interesting. :Just for my own clarification... how would this be different than NFS :(specifically local NFS)? : :-- :David Cross | email: cro...@cs.rpi.edu :Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd NFS isn't a fun protocol to implement. I'd implement a user-level filesystem interface protocol like this: * Have a device similar to portal that a user process can open for the server interface. * Have the ability to mount the 'client side' of the device once the 'server side' has been opened by the user process. * VOP Requests through the mount point are routed to the user process and responses returned. * Device driver handles auto termination of any pending commands if the user process close()'s the server side interface. * User process uses read() and write() to read request structures and write back response structures. (Thus the user process can use select() if it wishes). The request structure can contain a data pointer & length. If the device is passing a read or write request to the user level server, it mmap's the data block into the server's address space prior to queueing the command and unmaps it after receiving the response. It would be really cool if someone were to write something like this. I don't think it would be terribly difficult except for the mmap() piece. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: softupdates on root partition, no floppy
On Saturday, 17th July 1999, Matthew Dillon wrote: >:Is there any way to force softupdate on on a mounted system, or do I have to >:either move the / to another machine, or move a floppydrive to this machine? > >If you boot single-user, root will be mounted read-only and you should >be able to 'tunefs -n enable /dev/rda0a' and reboot. I gave up using soft updates on root because of the delayed delete behaviour. I kept filling up root while updating kernels. It doesn't gain you much on little used file systems anyway. So, I recommend people leave root alone. Stephen. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
At 11:40 AM 18/07/99 -0700, you wrote: >Tim Baird wrote: > >> I hope everyone is benefitting by these simple facts > > *chuckle* "Simple facts.." You sound like my physics professor. I for > one >am benefitting very much from the discussion. I got hired at my current job >as a software person, but I have a background in hardware so I try and make >it into the NOC every excuse I get (promotability, don't you know). It >always helps if sound like I have a vague idea what I'm talking about. :) I'll take that as a compliment ;) > > I just made up my first ethernet cables the other day, and learned an >interesting tidbit that I'm sure is beyond elementary to most of you, but >may benefit someone else. What I was told is that the reason Cat 5 cable is >so much more efficient is that each of the 4 pairs of wire is twisted at a >different rate. This helps reduce the possibility of frequency >synchronization for the EM fields the pairs create. Your description (what you were told) here is incorrectthe number of twists in a cable had **NO** effect on the spectral content of the cunducted signal or resulting radiated/induced signal.to do so would require the conductors to have a nonlinear conduction characteristic which they most assuredly do not (for all practical purposes). The design of the cable is such that adjacent pairs have as little effectively parallel length as possible. Obviously, the currents in the wires share the same axis, so the magnetic coupling is only reduced by the fact that interfering magnetic fields will tend to induce a common mode current in adjacent pairs...particulary since both conductors in the receiving cable pair --on average-- are exposed equally, the idea in "randomizing" the twists is to reduce the capacitive coupling as much as possible. Capacitive coupling is a more localized effect, and thrives when conductors share a common plane in close proximity...this is why capacitors are designed as two metal plates very close together..the electric field between the plates (conductors) is much higher than if they were perpendicular...or not nicely parallel. I hope this clarifies the situation :) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Sun, 18 Jul 1999, Alex Zepeda wrote: > Perhaps if you explain what it is you're trying to accomplish, there might > be an easier option than porting *shudder* glibc? I need a libc 100% compatible with glibc to make porting (from Linux) easier. And, as a side note, I think both FreeBSD and Linux would benefit of having compatible libc:s. Perhaps porting BSD libc to Linux would be easier? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: > I need a libc 100% compatible with glibc to make porting (from Linux) > easier. And, as a side note, I think both FreeBSD and Linux would benefit > of having compatible libc:s. I seriously doubt this will make porting any easier. 99% of the porting issues you'll run into, are from a.) lack of sys/types.h being included, or order of headers being included. b.) dependencies on Linux-specific ioctls or syscalls, such as clone, which are not really libc related. c.) dependencies on bugs in glibc. > Perhaps porting BSD libc to Linux would be easier? I doubt it. The glibc has been designed with portability in mind (hell, it's purported to run on Irix), FreeBSD's with security and speed. - alex What I am is what I am, What you are is what you are - Edie Brickell (ain't she profound?) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999 sth...@nethelp.no wrote: > > > Please read the documentation. > > > > This is hard since the actual machines and switches are almost > > 6000 miles away from me and the last time I checked, it didn't come with > > manuals. I know my way around the Cisco routers but the switches is still > > a mystery... > > All of the Cisco documentation is available on WWW. Use it! I known it is but I was talking about the printed copy... > Start at http://www.cisco.com/, follow the "Technical documents" and > then the "Documentation home page" link. The manual for your switch is > available, that's where I found the "show mac-address-table" command. Atleast the Cisco documentation is good... The Ascend documentation sucks big time since none of the stuff in the manual matches the actual OS on the system. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining the return address
Wes Peters writes: > On the SPARC, FWIW, the return address is in %i7. What is difficult to > determine (programmatically) is if the function is a normal or leaf function; > different return sequences are used for each. It doesn't matter; all I need it for is to find the caller's name using dladdr(). 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: Determining the return address
Alfred Perlstein writes: > On 18 Jul 1999, Dag-Erling Smorgrav wrote: > > Hmm, I ended up using a global variable which I increment at the > > beginning of the signal handler, and decrement at the end. > As long as you make sure the code won't have multiple access > that would work. Signal handlers having multiple accesses? When did you last see that happen? 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: glibc
On Mon, 19 Jul 1999, Alex Zepeda wrote: > I seriously doubt this will make porting any easier. You think so? I experience a lot of this when I try to recompile stuff for FreeBSD (most of it are due to lack of a real getopt routine). > c.) dependencies on bugs in glibc. What bugs have you found in glibc 2.1.1? Have you reported those to the GNU folks? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: > You think so? Yes. > I experience a lot of this when I try to recompile stuff for FreeBSD > (most of it are due to lack of a real getopt routine). *sigh* It's quite easily argued that depending on a *NON STANDARD* getopt routine is a bug. AFAIK *ONLY* glibc has the long-getopt crap, and if that's the only thing you're running into, it should be easy enough to rip out the long getopt code, and add a few proper defines and have the standard libc coexist peacefully with the GNU getopt. > > c.) dependencies on bugs in glibc. > > What bugs have you found in glibc 2.1.1? Have you reported those to the > GNU folks? I personally haven't found any, but I've seen for instance, kcalc is riddled with ifdefs and warnings about floating point precision stuff and RH 5.something due to glibc bug(s). - alex I thought felt your touch In my car, on my clutch But I guess it's just someone who felt a lot like I remember you. - Translator To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: > > I guess I forgot about the overhead. I've tested between two > > FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL > > Switch Full Duplex and never seen anything close to the speeds. > > using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp > cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. > > i use these machines for stressing every else we have at work. Hmmm, has anyone tried a full duplex test before? Since it seems like the bottleneck is really the speed of the disks.. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
How much memory do we need to install?
AFAIK, the minimum memory for installation is still 5 MB, and the problems people had with 8MB machines failing to install was a bug, right? What's the current status? Greg - Forwarded message from Thierry Herbelot - > Delivered-To: freebsd-questi...@freebsd.org > Date: Mon, 19 Jul 1999 09:49:01 +0200 > Reply-To: thierry.herbe...@alcatel.fr > Organization: ALCATEL CIT Nanterre > X-Mailer: Mozilla 4.5 [en] (WinNT; I) > X-Accept-Language: en > To: Ben Salem > Cc: freebsd-questi...@freebsd.org > X-Loop: FreeBSD.ORG > Precedence: bulk > > You must have more than 8 Megs to install FreeBSD > > TfH > > Ben Salem wrote: >> >> Im attempting to install FreeBSD 3.2-RELEASE on a 486 8mb ram. >> >> Everything goes ok until the installation actually begins, it gets to >> chunk 1 of 106 then stops. >> >> The install seems to work fine on my other machines. >> >> I have replaced the NIC card, so I think I can rule that out. >> >> Any ideas? >> >> Thanks >> Ben Salem - End forwarded message - -- 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: poor ethernet performance?
Hi ... We have previously done many network performance tests for our products running on FreeBSD ... We have found that when ever there is disk accessing involved, it is not a good idea to look at the transfer figures. We did tests with ftp and is was slow (compared to only memory generated data e.g. ttcp) 1. If you want to test the network speed ... use ttcp or something that generates the data and doesn't read it from disk. 2. When doing full-duplex and using fxp cards, stay away from X-over cables ... use a full-duplex switch etc. ... the fxp cards are not made to work with X-over cables (as far as I know - ala Intel spec) note ... only for full-duplex tests. We have done tests in full-duplex with non Intel cards (because we did not have a switch at that time :)) and with max size packets we got around 188.00 Mbps using the de0 driver. Cheers Reinier > On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: > > > > I guess I forgot about the overhead. I've tested between two > > > FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco 2924XL > > > Switch Full Duplex and never seen anything close to the speeds. > > > > using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp > > cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. > > > > i use these machines for stressing every else we have at work. > > Hmmm, has anyone tried a full duplex test before? Since it seems > like the bottleneck is really the speed of the disks.. > > > Cheers, > Vince - vi...@mcestate.com - vi...@gaianet.net __ > Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] > GaiaNet Corporation - M & C Estate / / / / | / | __] ] > Beverly Hills, California USA 90210 / / / / / |/ / | __] ] > HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] > > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote: > Hi ... > > We have previously done many network performance tests for our > products running on FreeBSD ... > > We have found that when ever there is disk accessing involved, it > is not a good idea to look at the transfer figures. We did tests > with ftp and is was slow (compared to only memory generated data > e.g. ttcp) yeah, I guess all tests should be done without requiring the use of the disk. > 1. If you want to test the network speed ... use ttcp or something >that generates the data and doesn't read it from disk. ttcp works. The only problem is when I tried it in both directions, at once. the total becomes 11.xMbytes/sec total as opposed to 9.4Mbytes/sec when doing it in one direction only. > 2. When doing full-duplex and using fxp cards, stay away from X-over >cables ... use a full-duplex switch etc. ... the fxp cards are not >made to work with X-over cables (as far as I know - ala Intel spec) >note ... only for full-duplex tests. Does anyone actually use X-over cables for 100Mbps Full Duplex since 3Com said CrossOver cables are not rated for 100Mbps or something even though it's Cat5. Actually, in the older Intel docs for the Pro100B, it does say to connect using X-over cable to the switch. > We have done tests in full-duplex with non Intel cards (because we did > not have a switch at that time :)) and with max size packets we got around > 188.00 Mbps using the de0 driver. Pretty interesting. How did you do the full duplex tests? Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] > > On Sun, 18 Jul 1999, Jonathan M. Bresler wrote: > > > > > > I guess I forgot about the overhead. I've tested between two > > > > FreeBSD machines using Intel Pro100+ NIC cards connected to a Cisco > > > > 2924XL > > > > Switch Full Duplex and never seen anything close to the speeds. > > > > > > using netperfv2pl3 and FreeBSD 2.2.8 on 300MHz PII with fxp > > > cards (all from memory), i routinely get TCP_STREAM to pushd 94Mbps. > > > > > > i use these machines for stressing every else we have at work. > > > > Hmmm, has anyone tried a full duplex test before? Since it seems > > like the bottleneck is really the speed of the disks.. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Buildworld failing from 3.1 to 3-2.stable...
I have a box running 3.1-stable that I wanted to update. sups fine, but the build dies in login with: ===> usr.bin/login cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -c /n/FreeBSD/RELENG_3 /src/usr.bin/login/login.c /n/FreeBSD/RELENG_3/src/usr.bin/login/login.c: In function `main': /n/FreeBSD/RELENG_3/src/usr.bin/login/login.c:129: warning: argument `argv' might be clobbered by `longjmp' or `vfork' cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -c /n/FreeBSD/RELENG_3 /src/usr.bin/login/login_access.c cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -c /n/FreeBSD/RELENG_3 /src/usr.bin/login/login_fbtab.c cc -O -pipe -static -Wall -DLOGIN_ACCESS -DLOGALL -I/usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/include -o login login.o logi n_access.o login_fbtab.o -lutil -lcrypt -lpam /usr/obj/n/FreeBSD/RELENG_3/src/tmp/usr/lib/libpam.a(pam_static_modules.o): In function `_pam_get_static_sym': pam_static_modules.o(.text+0x179): undefined reference to `skeyaccess' pam_static_modules.o(.text+0x275): undefined reference to `rad_create_request' pam_static_modules.o(.text+0x283): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x29d): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2b2): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2dc): undefined reference to `rad_put_string' pam_static_modules.o(.text+0x2ea): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x308): undefined reference to `rad_put_attr' pam_static_modules.o(.text+0x316): undefined reference to `rad_strerror' pam_static_modules.o(.text+0x32a): undefined reference to `rad_put_int' pam_static_modules.o(.text+0x33e): undefined reference to `rad_strerror' stdin What am I missing here? To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
2nd draft: README.serial for handbook
The second draft of the serial console section in the FreeBSD handbook is ready. It is available at the same URL as below. Please review and correct any technical, grammatical, or whatever errors. Thank you. Kazu >>From time to time people ask questions about the serial console. As >README.serial is buried deep inside the kernel source tree, it's almost >time to have a decent text on the serial console in our handbook. > >I am reformatting README.serial so that it can be included in our >handbook, and adding bits and pieces to clarify things. I haven't >finished it yet, but would like to have your comments now, so that we >can make it more informative and useful. > >I put up the HTML version in: > > http://www.freebsd.org/~yokota/serialconsole.html > >and the SGML version in: > > http://www.freebsd.org/~yokota/serial-console.sgml > >Please have a look and send me comments, corrections, additional >useful text, relevant pointers, etc. > >Some notes: > >- The text describes FreeBSD versions 3.0 and 3.1 or later. Version >3.0 doesn't have our new boot loader, so there is a note in the >introduction section about it. > >- Because there are many differences regarding the serial console >setup between 2.X systems and 3.X systems, I don't directly deal with >2.X systems in this text. > >- I am not a SGML expart ;-< formatting and links may be wrong. > >- Some sections are not yet finished :-) > >- The chapter number is arbitrary. When this text will be eventually >included in the handbook, I expect Nik will put it somewhere suitable >and give appropriate chapter number. > > >Thank you. > >Kazu > >PS: I don't subscribe to the doc ML. Please send mail to the hackers ML >or to me directly. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: All this and documentation too? (was: cvs commit: src/sys/isa sio.c)
> [trimming CC list] > > Dag-Erling Smorgrav wrote: > > > > Greg Lehey writes: > > > mdoc.samples(7). Now tell me that that's not intuitive. > > > > It would seem mdoc.samples(7) does not teach by example :) > > > > d...@des ~% man -t mdoc.samples | lpr -Plex > > Usage: .Rv -std sections 2 and 3 only > > This is a bug in man, actually. Section 7 is misc, and anything > *can* go there. It's perfectly possible to have something in need of > section 2/3 features that happens not to qualify as section 2 or 3. It isn't a bug in man. It is a problem with the mdoc macro package. Technically, mdoc.samples is using a *roff macro in a section that shouldn't be using that macro (the .Rv macro). I've known about this problem for quite some time, but just haven't been willing to commit the fix, since mdoc.samples(7) is the only man page that spits out this error. I do have a fixed version of the mdoc macro package that ignores this error for section 7 man pages. Since I've seen a few comments on this in the past few months, I suppose I'll break down and commit my changes. -- Mike Pritchard m...@freebsd.org or m...@mpp.pro-ns.net To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
Hi .. > > 1. If you want to test the network speed ... use ttcp or something > >that generates the data and doesn't read it from disk. > > ttcp works. The only problem is when I tried it in both > directions, at once. the total becomes 11.xMbytes/sec total as opposed to > 9.4Mbytes/sec when doing it in one direction only. If the devices are set at full-duplex then you are looking at something else ... the standard size for ttcp packets is 8k ... maybe the switch etc. that you are connected to doesn't handle fragmented packets very well. But ... what it rather seems like .. is that the devices are not in full-duplex mode generating a lot of collisions. After a test with transfers in both directions .. check the number of collisions with "netstat -in". If the number of collisions is not high .. - wait a moment ... are you using ttcp with tcp or udp option ... if you are using tcp (the default) then when transfering data you have acks going in both directions which could cause collisions on a full-duplex line ... try the same with the -u option for UDP. Check our setup below ... I'll explain some things there. Also check with "netstat -sn" to see if there are any other counters that increase with the full-duplex transfers. > > 2. When doing full-duplex and using fxp cards, stay away from X-over > >cables ... use a full-duplex switch etc. ... the fxp cards are not > >made to work with X-over cables (as far as I know - ala Intel spec) > >note ... only for full-duplex tests. > > Does anyone actually use X-over cables for 100Mbps Full Duplex > since 3Com said CrossOver cables are not rated for 100Mbps or something > even though it's Cat5. Actually, in the older Intel docs for the Pro100B, > it does say to connect using X-over cable to the switch. Yes ... to a switch maybe ... but not fxp to fxp ... when transfering small packets .. you get a lot of "device timeouts". > > We have done tests in full-duplex with non Intel cards (because we did > > not have a switch at that time :)) and with max size packets we got around > > 188.00 Mbps using the de0 driver. > > Pretty interesting. How did you do the full duplex tests? > I'll describe the setup briefly ... :) We had 3 machines two PII-400 as the generators and a PII-400 as the machine in the middle ... So we have a setup that looks like this ... - -- - | Gen 1 |-| Router |-| Gen 2 | - -- - Now .. here is a trick ... add entries manually in the Router's tables to simulate machines on each side that "does not exist". The reason for this is that we don't want the machines on the side to be generating AND excepting packets ... we just want them to generate packets at max network rate and nothing else. We then start a ttcp on both sides to the "non existing" machines. This means the router will be forwaring packets it receives without any machines having to be there because of the entries in the routing table. (we did this because we did not have another two fast machines at that time, but we did check the packets to make sure everything goes through and are not dropped etc. - it was some time ago :) ) We start ttcp with the following command ttcp -t -s -u -p 7000 -n -l 1472 10.0.0.1 the size of 1472 generates nice 1514 size UDP packets :) We then let the test run ... and check the throughput ... We used CAT5 X-over cables ... Hopw this helps Reinier To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: How much memory do we need to install?
3.2-RELEASE installs just fine on an 8 meg 386. -STABLE runs just fine. -Original Message- From: Greg Lehey [mailto:g...@lemis.com] Sent: Monday, July 19, 1999 2:04 AM To: Brian McGroarty; FreeBSD Hackers; FreeBSD Committers Subject: How much memory do we need to install? AFAIK, the minimum memory for installation is still 5 MB, and the problems people had with 8MB machines failing to install was a bug, right? What's the current status? Greg - Forwarded message from Thierry Herbelot - > Delivered-To: freebsd-questi...@freebsd.org > Date: Mon, 19 Jul 1999 09:49:01 +0200 > Reply-To: thierry.herbe...@alcatel.fr > Organization: ALCATEL CIT Nanterre > X-Mailer: Mozilla 4.5 [en] (WinNT; I) > X-Accept-Language: en > To: Ben Salem > Cc: freebsd-questi...@freebsd.org > X-Loop: FreeBSD.ORG > Precedence: bulk > > You must have more than 8 Megs to install FreeBSD > > TfH > > Ben Salem wrote: >> >> Im attempting to install FreeBSD 3.2-RELEASE on a 486 8mb ram. >> >> Everything goes ok until the installation actually begins, it gets to >> chunk 1 of 106 then stops. >> >> The install seems to work fine on my other machines. >> >> I have replaced the NIC card, so I think I can rule that out. >> >> Any ideas? >> >> Thanks >> Ben Salem - End forwarded message - -- 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 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Alex Zepeda wrote: > It's quite easily argued that depending on a *NON STANDARD* getopt routine > is a bug. I know it isn't standard. But it works well, and is used by a lot of programs. Perhaps it should have been put in another library than libc, though. Actually, I'd better suggest this to the GNU people right ahead. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, Jul 19, 1999, Per Lundberg wrote: > On Mon, 19 Jul 1999, Alex Zepeda wrote: > > > It's quite easily argued that depending on a *NON STANDARD* getopt routine > > is a bug. > > I know it isn't standard. But it works well, and is used by a lot of > programs. Perhaps it should have been put in another library than libc, > though. Actually, I'd better suggest this to the GNU people right ahead. What is the point of using GNU-getopt over the standard getopt other than --foo-bar flags that everyone I know hates? -- |Chris Costello |Watch out for off-by-one errors. `-- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: # On Mon, 19 Jul 1999, Alex Zepeda wrote: # # > It's quite easily argued that depending on a *NON STANDARD* getopt routine # > is a bug. # # I know it isn't standard. But it works well, and is used by a lot of # programs. Perhaps it should have been put in another library than libc, # though. Actually, I'd better suggest this to the GNU people right ahead. How about gnugetopt? FreeBSD already has a port, devel/libgnugetopt, that does this. :) -steve To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Chris Costello wrote: >What is the point of using GNU-getopt over the standard > getopt other than --foo-bar flags that everyone I know hates? Nothing. But I don't think they're as bad as you say, especially when you're new to a program and don't know the short options yet. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Steve Price wrote: > How about gnugetopt? FreeBSD already has a port, devel/libgnugetopt, > that does this. :) Great. I'll check this out. Thanks. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
Chris Costello wrote: > >What is the point of using GNU-getopt over the standard > getopt other than --foo-bar flags that everyone I know hates? Hi, I'm Daniel. Pleased to meet you. Now you know someone who doesn't hate it. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org Everything journalists write is true, except when they write about something you know. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, Jul 19, 1999, Daniel C. Sobral wrote: > Chris Costello wrote: > > > >What is the point of using GNU-getopt over the standard > > getopt other than --foo-bar flags that everyone I know hates? > > Hi, I'm Daniel. Pleased to meet you. Now you know someone who > doesn't hate it. Good morning, Daniel! As someone more helpful than myself in this thread has already pointed out, it seems, there is a port for the GNU getopt, known as 'libgnugetopt'. I would imagine this would help the thread's originator in porting the GNU utilities to FreeBSD. -- |Chris Costello |Hardware: The parts of a computer system that can be kicked. ` To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
Following up on my own post:
For LDAP to be seamlessly integrated into the system some of the libraries
have to be changed. Specifically the ones dealing with /etc/passwd and
user information.
I've decided the best way to do this is to do what's done with NIS.
Basically handle the case where the user is not available in the local
databases.
the idea is to have an entry in the /etc/passwd enabling LDAP lookups.
the Entry would be of the form
ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com
^^^ ^^^ ^^^ ^^
| |||
portbase dnattr LDAP Server
This comes ftom a pam_ldap module I got from Pedro A M Vazquez
I'll change all of the function in lib/libc/gen/getpwent.c to handle this
special case.
The only problem is that openldap has to be integrated on the base system
for this to compile... can I safely copy it to /usr/src/contrib?
How do I submit this after it's done? anyone cares about ldap :)?
Regards,
-Oscar
On Thu, Jul 15, 1999 at 08:03:36PM -0600, Oscar Bonilla wrote:
> While trying to use the pam_ldap module available from www.padl.com
> I discovered the following problem.
>
> although the module authenticates just fine (using openldap)
> the login program fails to permit logins. I traced the problem to
> login.c --- the following code is from login.c
>
> my questions are at the bottom.
>
>
>
>
> pwd = getpwnam(username);
>
> - at this point pwd == NULL due to the fact that the user
> - does not exist on the local passwd database... see below
>
> /*
>* if we have a valid account name, and it doesn't have a
>* password, or the -f option was specified and the caller
>* is root or the caller isn't changing their uid, don't
>* authenticate.
>*/
> if (pwd != NULL) {
> if (pwd->pw_uid == 0)
> rootlogin = 1;
>
> if (fflag && (uid == (uid_t)0 ||
> uid == (uid_t)pwd->pw_uid)) {
> /* already authenticated */
> break;
> } else if (pwd->pw_passwd[0] == '\0') {
> if (!rootlogin || rootok) {
> /* pretend password okay */
> rval = 0;
> goto ttycheck;
> }
> }
> }
>
> fflag = 0;
>
> (void)setpriority(PRIO_PROCESS, 0, -4);
>
> #ifndef NO_PAM
> /*
>* Try to authenticate using PAM. If a PAM system error
>* occurs, perhaps because of a botched configuration,
>* then fall back to using traditional Unix authentication.
>*/
> if ((rval = auth_pam()) == -1)
>
> - This returns PAM_SUCCESS since the pam_ldap module has
> - successfully identified and authenticated the user.
>
> #endif /* NO_PAM */
> rval = auth_traditional();
>
> (void)setpriority(PRIO_PROCESS, 0, 0);
>
> #ifndef NO_PAM
> /*
>* PAM authentication may have changed "pwd" to the
>* entry for the template user. Check again to see if
>* this is a root login after all.
>*/
> if (pwd != NULL && pwd->pw_uid == 0)
> rootlogin = 1;
> #endif /* NO_PAM */
>
> ttycheck:
> /*
>* If trying to log in as root without Kerberos,
>* but with insecure terminal, refuse the login attempt.
>*/
>
> - This next if is the problem: pwd == NULL from above,
> - and the user doesn't get in.
>
> if (pwd && !rval) {
> if (rootlogin && !rootok)
> refused(NULL, "NOROOT", 0);
> else/* valid password & authenticated */
> break;
> }
>
> (void)printf("Login incorrect\n");
> failures++;
>
>
>
> 1. what would be the right way to fix this?
>
> 2. after the user successfully logs in he still won't have an entry
>in the /etc/passwd database, so all syscalls having to do with
>identifying the user will fail... how can I have these funcions get
>their info from LDAP?
>
> I'm willing to patch and submit these programs, but would like some
> feedback about the right way to integrate this.
>
> I checked with
Re: softupdates on root partition, no floppy
> If you boot single-user, root will be mounted read-only and you should > be able to 'tunefs -n enable /dev/rda0a' and reboot. > > -Matt > Matthew Dillon > > It's a little bit simpler than that: in single user mode, tunefs -n enable / no reboot is necessary (tunefs reloads the fs after it makes changes on disk). -lq To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
bug in ip_forward() ?
I suspect a bug in IP forwarding. I'm using FreeBSD 2.2.8-RELEASE.
This is our network:
+--+ +--+ +--+ +--+
| |4.2 4.1| |2.1 2.2| |5.1 5.2| |
|btm22t|-|btm22q|-|btm22r|-|btm22u|
| | | | | | | |
+--+ +--+ +--+ +--+
And this is what I do:
btm22t# ping 192.168.5.2
ok, it works...
btm22q# route delete -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2
ok, ping stops.
btm22q# route add -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2
ping doesn't work
btm22t# ^C
btm22t# ping 192.168.5.2
ping still doesn't work
btm22t# ping 192.168.5.1 (or 192.168.2.2)
this ping works and suddenly the ping to 192.168.5.2 works too !
Although:
btm22t# ping 192.168.5.2
ok, it works...
btm22t# ^C
btm22q# route delete -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2
btm22q# route add -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2
btm22t# ping 192.168.5.2
ping works!
After disabling the cache in ip_forward() (netinet/ip_input.c)
i.e.:
sin = (struct sockaddr_in *)&ipforward_rt.ro_dst;
< if ((rt = ipforward_rt.ro_rt) == 0 ||
< ip->ip_dst.s_addr != sin->sin_addr.s_addr )
> if (1)
{
...
the problem doesn't occur!
Anyone has a clue what's wrong here ?
Thanks a lot,
Wim.
---
What follows is just some background info.
Relevant routes:
btm22t:
192.168/30 198.149.4.1UGS1c 00 fxp0
192.168.1/30 198.149.4.1UGS1c 00 fxp0
192.168.2/30 198.149.4.1UGS1c 02 fxp0
192.168.4/30 link#2 UC 00
192.168.4.10:50:8b:7:50:12UHLW0 139
btm22q:
192.168/30 link#2 UC 00
192.168.0.1link#2 UHLW2 11
192.168.1/30 192.168.0.1UGS1c 00 fxp1
192.168.2/30 link#3 UC 00
192.168.2.20:8:c7:b3:c8:c3UHLW1 44 fxp2927
192.168.3/30 192.168.0.1UGS1c 00 fxp1
192.168.4/30 link#1 UC 00
192.168.4.20:50:8b:7:54:2eUHLW1 4534 fxp0777
192.168.5/30 192.168.2.2UGSc02 fxp2
btm22r:
192.168/30 192.168.1.1UGS1c 00 fxp2
192.168.1/30 link#3 UC 00
192.168.1.1link#3 UHLW1 103
192.168.2/30 link#2 UC 00
192.168.2.10:50:8b:7:49:17UHLW1 145 fxp1895
192.168.4/30 192.168.2.1UGS1c 1 21 fxp1
192.168.5/30 link#1 UC 00
192.168.5.20:50:8b:7:54:33UHLW0 275355 fxp0505
btm22u:
192.168.2/30 192.168.5.1UGS1c 0 16 fxp1
192.168.4/30 192.168.5.1UGS1c 06 fxp1
192.168.5/30 link#2 UC 00
192.168.5.10:50:8b:7:49:7dUHLW20 fxp1489
dmesg on btm22q:
FreeBSD 2.2.8-RELEASE #0: Fri Jul 16 15:34:52 CEST 1999
r...@btm22u.rc.bel.alcatel.be:/usr/src/sys-cvs/sys/compile/CUSTOM
CPU: Pentium II (quarter-micron) (348.49-MHz 686-class CPU)
Origin = "GenuineIntel" Id = 0x652 Stepping=2
Features=0x183f9ff,,MMX,<
b24>>
real memory = 67108864 (65536K bytes)
avail memory = 63123456 (61644K bytes)
altq: major number is 96
Probing for devices on PCI bus 0:
chip0 rev 2 on
pci0:0:0
chip1 rev 2 on
pci0:1:0
fxp0 rev 5 int a irq 11 on pci0:13:0
fxp0: Ethernet address 00:50:8b:07:50:12
fxp1 rev 5 int a irq 11 on pci0:14:0
fxp1: Ethernet address 00:50:8b:07:4b:f6
fxp2 rev 5 int a irq 11 on pci0:15:0
fxp2: Ethernet address 00:50:8b:07:49:17
chip2 rev 3 on
pci0:16:0
chip3 rev 2 on pci0:20:0
chip4 rev 1 on pci0:20:1
chip5 rev 1 int d irq 11 on pci0:20:2
chip6 rev 2 on pci0:20:3
Probing for devices on PCI bus 1:
vga0 rev 1 int a irq 11 on pci1:0:0
Probing for devices on PCI bus 2:
de0 rev 34 int a irq 11 on pci2:4:0
de0: ZNYX ZX34X 21140A [10-100Mb/s] pass 2.2
de0: address 00:c0:95:e0:e3:70
de1 rev 34 int a irq 11 on pci2:5:0
de1: ZNYX ZX34X 21140A [10-100Mb/s] pass 2.2
de1: address 00:c0:95:e0:e3:71
de2 rev 34 int a irq 11 on pci2:6:0
de2: ZNYX ZX34X 21140A [10-100Mb/s] pass 2.2
de2: address 00:c0:95:e0:e3:72
de3 rev 34 int a irq 11 on pci2:7:0
de3: ZNYX ZX34X 21140A [10-100Mb/s] pass 2.2
de3: address 00:c0:95:e0:e3:73
Probing for PnP devices:
No Plug-n-Play devices were found
Probing for devices on the ISA bus:
sc0 at 0x60-0x6f irq 1 on motherboard
sc0: VGA color <16 virtual consoles, flags=0x0>
ed0 not found at 0x300
psm0 not found at 0x60
sio0 at 0x3f8-0x3ff irq 4 on isa
sio0:
Re: Determining the return address
On 19 Jul 1999, Dag-Erling Smorgrav wrote: > Alfred Perlstein writes: > > On 18 Jul 1999, Dag-Erling Smorgrav wrote: > > > Hmm, I ended up using a global variable which I increment at the > > > beginning of the signal handler, and decrement at the end. > > As long as you make sure the code won't have multiple access > > that would work. > > Signal handlers having multiple accesses? When did you last see that > happen? erm, can't you point multiple signal handler entries to the same routine? can't you also make it so that signals aren't defered or blocked while another handler is executing so you may actually re-enter the handler before it's complete. specifically how you say you increment it, then decrement it, if you have multiple handlers where one can interupt another you can have the counter get jumbled. -Alfred To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Overcommit and calloc()
> > On the other hand, I find the discussion about the merits of overcommit > and the (albeit not always in-depth) explanations of the FreeBSD VM system > educational. It would be nice if would could just extract the small amount > of signal from this discussion and put it into documentation somewhere. > Also, it has got me thinking: does FreeBSD overcommit memory allocated by > calloc()? Seems that it would be difficult since the page would > have had to > have been touched in order be zeroed, but I was curious. > I'm afraid my question got lost amongst the see of overcommit messages. :) I was curious if calloc() was overcommitted also? Or is it more fundamental than that and the kernel always overcommits memory, which processes claim via sbrk, but which, when finally touched by the app, the kernel fills with a zero'ed page. If my scenario is correct, what affect does our malloc() algorithm have, if any...in other words, is there any way to reclaim memory which was returned to the heap via free(), but which malloc() can't sbrk back to the system? Does it matter? The scenario I think of is a process malloc()'ing a large amount of memory (which is implemented by increasing the process' address space via sbrk), then malloc()'ing another chunk of memory (again, sbrk'ing). Finally, freeing the memory allocated via the first call to malloc(). Now there is a large hole in the process' address space, which presumably will be backed by swap when in fact it is useless. I can't think of any way around that, nor can I imagine it is that great of a problem, but then again, I don't know everything :) I was curious what some of the gurus thought. Thanks, Kelly ~kby...@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining the return address
Alfred Perlstein writes: > erm, can't you point multiple signal handler entries to the same > routine? can't you also make it so that signals aren't defered > or blocked while another handler is executing so you may actually > re-enter the handler before it's complete. I use good ol' signal() rather than sigaction(), so no, signals can't interrupt one another's handlers. > specifically how you say you increment it, then decrement it, > if you have multiple handlers where one can interupt another > you can have the counter get jumbled. Not if increment / decrement is atomic. 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: glibc
> (most of it are due to lack of a real getopt routine). FreeBSD does have a real, 100% posix compatible getopt. Maybe you are missing one of the numerous, non-standard Linux extentions? Gnu's getopt can be found in about a dozen different places in the FreeBSD tree. cvs, tar, etc. Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
In message Per Lundberg writes: : I know it isn't standard. But it works well, and is used by a lot of : programs. Perhaps it should have been put in another library than libc, : though. Actually, I'd better suggest this to the GNU people right ahead. There has been talking of having a libgnu.a to contain common routines like the long getopt... Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
In message <19990719080712.a15...@holly.dyndns.org> Chris Costello writes: : getopt other than --foo-bar flags that everyone I know hates? Not everyone hates them... Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Warner Losh wrote: > There has been talking of having a libgnu.a to contain common > routines like the long getopt... Yeah, I was thinking about something like that. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Overcommit and calloc()
"Kelly Yancey" writes:
> I'm afraid my question got lost amongst the see of overcommit messages. :)
> I was curious if calloc() was overcommitted also?
Here's our calloc() implementation:
void *
calloc(num, size)
size_t num;
register size_t size;
{
register void *p;
size *= num;
if ( (p = malloc(size)) )
bzero(p, size);
return(p);
}
so the answer is yes, it overcommits, but the bzero() may cause the
system to run out of swap.
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: PAM & LDAP in FreeBSD
Oscar Bonilla writes: > the idea is to have an entry in the /etc/passwd enabling LDAP lookups. > the Entry would be of the form > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com Horrible idea. 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: PAM & LDAP in FreeBSD
On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: > Oscar Bonilla writes: > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups. > > the Entry would be of the form > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com > > Horrible idea. > suggestions? -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
Oscar Bonilla writes: > On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: > > Oscar Bonilla writes: > > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups. > > > the Entry would be of the form > > > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com > > Horrible idea. > suggestions? /etc/auth.conf 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: PAM & LDAP in FreeBSD, and userfs too.
I thought now would be a good time to chime in on some of my wild schemes... The reason I am interested in 'userfs' is to enable me to write a version of 'nsd'. Those of you familiar with Irix will recognize it. For others, what it does is to present the name-space on a machine as filespace. The advantages of this is that we can greatly simplify out libc to use the file/namespace that nsd provides. For example 'getpwent()' now becomes file accesses to /ns/.local/passwd/NAME. Another advantage that this abstraction provides is that it allows transparent alterations of the databases in use, even to the extent of NOT having to restart each client that may be using a specific database. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: Overcommit and calloc()
Ahh...but wouldn't the bzero() touch all of the memory just allocated
functionally making it non-overcommit? I realize that technically it isn't
the same since although calloc() would ensure the memory actually was
committed (again, since the bzero() touches all the pages), if there weren't
enough pages free then a random process would still be killed rather than
returning null.
Believe me, I'm not trying to start that war again :) I'm just pointing
out that while technically it is still overcommit, it will touch the pages
ensuring that the memory does in fact exist (is committed). Perhaps this is
why I've always heard we should avoid calloc() because it is 'slow'?
Thanks for the great feedback, I should kick myself for now digging my
hands in the mud myself (I assumed it was more complicated than that :) ).
Kelly
~kby...@posi.net~
FreeBSD - The Power To Serve - http://www.freebsd.org/
Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD
> -Original Message-
> From: Dag-Erling Smorgrav [mailto:d...@flood.ping.uio.no]
> Sent: Monday, July 19, 1999 12:07 PM
> To: Kelly Yancey
> Cc: hack...@freebsd.org
> Subject: Re: Overcommit and calloc()
>
>
> "Kelly Yancey" writes:
> > I'm afraid my question got lost amongst the see of overcommit
> messages. :)
> > I was curious if calloc() was overcommitted also?
>
> Here's our calloc() implementation:
>
> void *
> calloc(num, size)
> size_t num;
> register size_t size;
> {
> register void *p;
>
> size *= num;
> if ( (p = malloc(size)) )
> bzero(p, size);
> return(p);
> }
>
> so the answer is yes, it overcommits, but the bzero() may cause the
> system to run out of swap.
>
> 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: USFS (User Space File System)
On Sun, 18 Jul 1999, Boris Popov wrote: > On Sat, 17 Jul 1999, David E. Cross wrote: > > I am looking at a project that will require a user based process to interact > > with the system as if it were a filesystem. The traditional way I have > > seen > > That type of file system is very useful for simple tasks. A while > ago I'm experementing with 'IPX network browser' which shows NetWare > servers as directories and allows to go down to see volumes, print queues > etc. > It would be nice if we're have something like 'userfs' (or > 'daemonfs') with unified interface and mount command like this: > > # mount_user /mydaemon /mountpoint > > so, all that I need to create a new file system is to write > 'mydaemon' program. Great idea. I liked it so much I bought the company -- er, I mean, I wrote something like this. It's private name spaces for Linux and FreeBSD (among others) and it allows you to mount things from remote file servers into your name space. There's a technical paper at www.acl.lanl.gov/~rminnich that is a brief overview. I'll get longer technical papers and such out there this week I hope. Writing servers is pretty easy, I have two reference implementations. In fact one server is a .c file plus a server library, so the actual server is quite small. Remaining task is to get a VFS for FreeBSD. The v9fs is a start but I need help getting the rest done. It's pretty easy to do though -- I was amazed at how quickly the Linux version went once I had a v9fs-like VFS for Linux. If interested let me know. ron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Overcommit and calloc()
"Kelly Yancey" writes: > Ahh...but wouldn't the bzero() touch all of the memory just allocated > functionally making it non-overcommit? No. If it were an "non-overcomitting malloc", it would return NULL and set errno to ENOMEM, instead of dumping core. 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: USFS (User Space File System)
On Mon, 19 Jul 1999, Ronald G. Minnich wrote: > Great idea. I liked it so much I bought the company -- er, I mean, I wrote > something like this. It's private name spaces for Linux and FreeBSD (among > others) and it allows you to mount things from remote file servers into > your name space. I forgot to make this clear: it's a full-fledged VFS on linux supporting things like mmap etc. It is indistinguishable to any process as being anything other than a file system -- because it is a file system. It's just that mounts into the file system are controlled by your process, not by /etc/fstab. Different groups of processes can have totally different sets of mount points. In fact one test is to have a login that does a chroot to a totally empty tree. You then mount things like /usr/bin, etc. into your private tree and at that point all programs run quite normally. If you want ou even get translucent file system behaviour for free, since the file system supports union mounts and the Plan 9 semantics are that the "top" mount is where files get created. A user can thus have read-only mounts from a server or servers somewhere, mount local disk on top, and voila: all new files are local. This would also support booting from a CDROM and running even though the local disk is either nonexistant or empty of any system files. Stacking comes for free too, of course. ron p.s. I looked at the "VOP upcall" idea but there's lots of interesting issues as regards parameters in the VOP structures being handed out to a user process and then back to the kernel. I'm not sure it's a good idea. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Overcommit and calloc()
In the last episode (Jul 19), Dag-Erling Smorgrav said: > "Kelly Yancey" writes: > > Ahh...but wouldn't the bzero() touch all of the memory just > > allocated functionally making it non-overcommit? > > No. If it were an "non-overcomitting malloc", it would return NULL > and set errno to ENOMEM, instead of dumping core. It should be possible to modify calloc to trap signals, then bzero. If bzero faults, you free the memory and return NULL. No, wait. You can't trap SIGKILL. How about this. mmap() some anonymous memory MAP_SHARED, fork a child to bzero it. If the child dies, unmmap and return NULL. If the child succeeds, use the memory. This memory won't be freeable with malloc(), though. -Dan Nelson dnel...@emsphone.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
> We have previously done many network performance tests for our > products running on FreeBSD ... > > We have found that when ever there is disk accessing involved, it > is not a good idea to look at the transfer figures. We did tests > with ftp and is was slow (compared to only memory generated data > e.g. ttcp) > > 1. If you want to test the network speed ... use ttcp or something >that generates the data and doesn't read it from disk. > absolutely right. netperf generates its own data on the fly. it does not generate any disk activity. > 2. When doing full-duplex and using fxp cards, stay away from X-over >cables ... use a full-duplex switch etc. ... the fxp cards are not >made to work with X-over cables (as far as I know - ala Intel spec) >note ... only for full-duplex tests. hmmi have used intel cards on a cross-over cable regularly without any problems whatsoever. jmb To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
On Mon, 19 Jul 1999, Per Lundberg wrote: > On Mon, 19 Jul 1999, Alex Zepeda wrote: > > > It's quite easily argued that depending on a *NON STANDARD* getopt routine > > is a bug. > > I know it isn't standard. But it works well, and is used by a lot of > programs. Perhaps it should have been put in another library than libc, > though. Actually, I'd better suggest this to the GNU people right ahead. If you give me documentation on it, I'll implement it for the BSD libc. It would be nice to go in, perhaps as a weak symbol (to remain compatible with FreeBSD packages including their own getopt.) And don't tell me to look at the getopt long code itself. That stuff is sickening. I just want the [exact] API. > > > > 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: glibc
On Mon, 19 Jul 1999, Warner Losh wrote: > In message > Per Lundberg writes: > : I know it isn't standard. But it works well, and is used by a lot of > : programs. Perhaps it should have been put in another library than libc, > : though. Actually, I'd better suggest this to the GNU people right ahead. > > There has been talking of having a libgnu.a to contain common > routines like the long getopt... How about libcompat/gnu/? > > Warner > > > 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: PAM & LDAP in FreeBSD
On Mon, Jul 19, 1999 at 06:22:17PM +0200, Dag-Erling Smorgrav wrote: > Oscar Bonilla writes: > > On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: > > > Oscar Bonilla writes: > > > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups. > > > > the Entry would be of the form > > > > > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com > > > Horrible idea. > > suggestions? > > /etc/auth.conf > Given that this is a PAM module, wouldn't /etc/pam.conf be more appropriate? Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.steven...@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
In article , Brian F. Feldman wrote: > [GNU getopt] > If you give me documentation on it, I'll implement it for the BSD libc. Note, we already have GNU getopt in the source tree in libiberty (in two different places -- binutils and gdb). It might be better just to install libiberty from one of those places. Left as an exercise for the reader: Figure out how the two differ and which one is "better". :-) 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: glibc
On Mon, 19 Jul 1999, John Polstra wrote: > In article , > Brian F. Feldman wrote: > > > [GNU getopt] > > If you give me documentation on it, I'll implement it for the BSD libc. > > Note, we already have GNU getopt in the source tree in libiberty (in > two different places -- binutils and gdb). It might be better just > to install libiberty from one of those places. But it would be nice to have a free long getopt implementation. > > Left as an exercise for the reader: Figure out how the two differ > and which one is "better". :-) I'd rather hurt myself severely. Wait a second, that's exactly what I'd be doing in the first place to do what you asked! Hm > > 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: glibc
Brian F. Feldman wrote: > On Mon, 19 Jul 1999, John Polstra wrote: > >> Left as an exercise for the reader: Figure out how the two differ >> and which one is "better". :-) > > I'd rather hurt myself severely. Of course. That's a prerequisite for becoming a committer. :-) 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: glibc
On Mon, 19 Jul 1999, Warner Losh wrote: > In message <19990719080712.a15...@holly.dyndns.org> Chris Costello writes: > : getopt other than --foo-bar flags that everyone I know hates? > > Not everyone hates them... Sure, I don't hate them either... until I try and port something that depends on them. Then I get annoyed. Some sort of compatible extension should be devised, so that a small block of code could be ifdef'd to provide support for long options, and the rest would work with a standard getopt routine. - 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: Overcommit and calloc()
> -Original Message- > From: Dag-Erling Smorgrav [mailto:d...@flood.ping.uio.no] > Sent: Monday, July 19, 1999 12:39 PM > To: Kelly Yancey > Cc: Dag-Erling Smorgrav; freebsd-hackers@freebsd.org > Subject: Re: Overcommit and calloc() > > > "Kelly Yancey" writes: > > Ahh...but wouldn't the bzero() touch all of the memory just allocated > > functionally making it non-overcommit? > > No. If it were an "non-overcomitting malloc", it would return NULL and > set errno to ENOMEM, instead of dumping core. > I guess I was looking at it from the commitment of memory point-of-view. Calloc() calls malloc() to get the memory (which will overcommit); calloc() then touches every page of the memory using bzero(). The memory itself will be committed. The only aspect of non-overcommit that it doesn't do is kindly tell the process if it couldn't touch every page, instead the overcommit model kills a process to reclaim pages so the bzero() will succeed (assuming we're not the unfortunate process :) ). You are absolutely right, calloc() doesn't act like a non-overcommit calloc() would, but it does in fact commit the memory. I don't know how many programs make use of calloc() but would not a more efficient algorithm be to better integrate it with malloc() such that if there is a fragment on the heap which can be used, bzero() it and return that, otherwise, simply call sbrk() and return that (since it is already zero'ed). Currently, in the event that malloc() simply returns newly sbrk()'ed memory, we unnecessarily zero it again. And yes, if the majority of people think this is worthwhile and I'm not just complete wrong here, then I'm glad to submit the patches. Kelly ~kby...@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: telnetd
On Sat, 17 Jul 1999, Warner Losh wrote: > What purpose is served by the twisty maze of ifdefs in telnetd? I'd > like to unifdef many of them. I'm trying to track down a bug and the > twisty maze makes it very hard to follow. Comments? There seem to be some fairly stupid ones in src/sbin too. ./dump/optr.c:#if __STDC__ ./init/init.c:#ifdef __STDC__ ./newfs/mkfs.c:#ifdef __ELF__ ./newfs/newfs.c:#if __STDC__ ./mount_ntfs/mount_ntfs.c:#if __FreeBSD_version >= 30 [...] how likely are the above to change. (some of them will never change, considering what branch they're on.) - 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
Re: System unique identifier.....
> > > Mike Smith wrote: > > > > > > > > The loader will, at some stage in the future, grow a persistent data > > > > store in which items like this can be saved. > > > > > > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent > > > data storage? > > > > There is little or no chance that the loader will gain the ability to > > write back to filesystems. Some of them don't support it (eg. > > iso9660), others may not (TFTP, NFS), and the code required for some of > > them (especially UFS) would be problematically large. > > But that's okay. If the persistent storage is the loader conf files, they > can be updated from single or multi-user mode. There are cases where they need to be updated _by_the_loader_; see eg. the "nextboot" manpage for functionality that we have currently lost. -- \\ 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: System unique identifier.....
> > > > Mike Smith wrote: > > > > > > > > > > The loader will, at some stage in the future, grow a persistent data > > > > > store in which items like this can be saved. > > > > > > > > Doesn't /boot/[defaults/]loader.conf[.local] qualify as persistent > > > > data storage? > > > > > > There is little or no chance that the loader will gain the ability to > > > write back to filesystems. Some of them don't support it (eg. > > > iso9660), others may not (TFTP, NFS), and the code required for some of > > > them (especially UFS) would be problematically large. > > > > But that's okay. If the persistent storage is the loader conf files, they > > can be updated from single or multi-user mode. > > There are cases where they need to be updated _by_the_loader_; see eg. > the "nextboot" manpage for functionality that we have currently lost. So much the better. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: glibc
> On Sun, 18 Jul 1999, Alex Zepeda wrote: > > > Perhaps if you explain what it is you're trying to accomplish, there might > > be an easier option than porting *shudder* glibc? > > I need a libc 100% compatible with glibc to make porting (from Linux) > easier. And, as a side note, I think both FreeBSD and Linux would benefit > of having compatible libc:s. Uh, if you are using libc correctly, there should be no porting issues at all. > Perhaps porting BSD libc to Linux would be easier? Perhaps you should just fix the applications in the first place? -- \\ 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: bug in ip_forward() ?
Wim Livens wrote: > > I suspect a bug in IP forwarding. I'm using FreeBSD 2.2.8-RELEASE. > > This is our network: > > +--+ +--+ +--+ +--+ > | |4.2 4.1| |2.1 2.2| |5.1 5.2| | > |btm22t|-|btm22q|-|btm22r|-|btm22u| > | | | | | | | | > +--+ +--+ +--+ +--+ > > And this is what I do: > > btm22t# ping 192.168.5.2 > ok, it works... > btm22q# route delete -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 > ok, ping stops. > btm22q# route add -net 192.168.5.0 -netmask 255.255.255.252 192.168.2.2 > ping doesn't work And it shouldn't, you haven't given it an appropriate route. From route(8): The other commands have the following syntax: route [-n] command [-net | -host] destination gateway where destination is the destination host or network, gateway is the next-hop intermediary via which packets should be routed. There's the important part right there: gateway is the *next-hop* intermediary via which packets should be routed. -- "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: softupdates on root partition, no floppy
> > If you boot single-user, root will be mounted read-only and you should > > be able to 'tunefs -n enable /dev/rda0a' and reboot. > > > > -Matt > > Matthew Dillon > > > > > It's a little bit simpler than that: in single user mode, tunefs -n enable / > no reboot is necessary (tunefs reloads the fs after it makes changes on disk). Unfortunately it doesn't first check to see if the fs is already loaded (so the reload generates a scary error message on all the other fs'es). -- \\ 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: PAM & LDAP in FreeBSD
> On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: > > Oscar Bonilla writes: > > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups. > > > the Entry would be of the form > > > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com > > > > Horrible idea. > > > > suggestions? Use PAM. -- \\ 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
Sv: softupdates on root partition, no floppy
From: Stephen McKay > On Saturday, 17th July 1999, Matthew Dillon wrote: > > >:Is there any way to force softupdate on on a mounted system, or do I have to > >:either move the / to another machine, or move a floppydrive to this machine? > > > >If you boot single-user, root will be mounted read-only and you should > >be able to 'tunefs -n enable /dev/rda0a' and reboot. > > I gave up using soft updates on root because of the delayed delete > behaviour. I kept filling up root while updating kernels. It doesn't > gain you much on little used file systems anyway. So, I recommend > people leave root alone. > Well, this disk is 4G and has only one partition, containing both / and /usr, so I think I may benefit from softupdates. Leif To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD, and userfs too.
On Mon, Jul 19, 1999 at 12:29:48PM -0400, David E. Cross wrote: > I thought now would be a good time to chime in on some of my wild schemes... > > The reason I am interested in 'userfs' is to enable me to write a version > of 'nsd'. Those of you familiar with Irix will recognize it. For others, > what it does is to present the name-space on a machine as filespace. > The advantages of this is that we can greatly simplify out libc to use the > file/namespace that nsd provides. For example 'getpwent()' now becomes > file accesses to /ns/.local/passwd/NAME. Another advantage that this > abstraction provides is that it allows transparent alterations of the > databases in use, even to the extent of NOT having to restart each client > that may be using a specific database. Lovely. Sounds like a much better way to do the Solaris/Linux (and NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is implemented using masses of weird shared objects... -- Dom Mitchell -- Palmer & Harvey McLane -- Unix Systems Administrator In Mountain View did Larry Wall Sedately launch a quiet plea: That DOS, the ancient system, shall On boxes pleasureless to all Run Perl though lack they C. -- ** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. ** To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
> Mike Smith wrote: > > On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: > > > Oscar Bonilla writes: > > > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups. > > > > the Entry would be of the form > > > > > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com > > > > > > Horrible idea. > > > > > > > suggestions? > > Use PAM. PAM isn't going to cut it. This is outside of its realm. Things like ps, top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able to pull 'passwd' entries from the LDAP server, and unless we PAM all of those (I think that is a very bad idea), then a person will be able to login but will be dead in the water without a UID <->Username mapping. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD, and userfs too.
On Mon, 19 Jul 1999 20:44:18 +0100 Dominic Mitchell wrote: > Lovely. Sounds like a much better way to do the Solaris/Linux (and > NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is > implemented using masses of weird shared objects... The plan for NetBSD is that things will also be handled with dynamic modules, but those dynamic modules will be glued into a `nscd'[*] (if you use Solaris, you're familiar with the name :-). [*] We are planning on not having all of the problems that the Solaris nscd has, and that people often complain about. This will allow libc to simply make a call to nscd (or fallback onto traditional `files' lookup), and nscd will handle all but the `files' case. This allows system-wide caching, and puts all of the complexity in one place. Involving one or more user mode file systems seems like ... the wrong approach for a name service switch. -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Anything special with kmem_map and mb_map?
I have been wondering this for some time. There are many kernel submaps: exec_map, clean_map, etc. But if you look the code in vm_map_find(), we have to call splvm() for kmem_map and its submap mb_map, but not for other kernel submaps. So is there anything special with these two kernel submaps? Thanks for any help. -Zhihui To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Mon, 19 Jul 1999 15:47:33 -0400 "David E. Cross" wrote: > PAM isn't going to cut it. This is outside of its realm. Things like ps, > top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able > to pull 'passwd' entries from the LDAP server, and unless we PAM all of those > (I think that is a very bad idea), then a person will be able to login but > will be dead in the water without a UID <->Username mapping. What you want is nsswitch, a'la Solaris. nsswitch tells you what the user's name is, PAM tells you how that user is to authenticate himself. The two things are orthogonal, and nsswitch and PAM together can work quite well. Solaris, for example, has both. -- Jason R. Thorpe To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: Overcommit and calloc()
> -Original Message- > From: Dan Nelson [mailto:dnel...@emsphone.com] > Sent: Monday, July 19, 1999 12:55 PM > To: Dag-Erling Smorgrav > Cc: Kelly Yancey; freebsd-hackers@FreeBSD.ORG > Subject: Re: Overcommit and calloc() > > > In the last episode (Jul 19), Dag-Erling Smorgrav said: > > "Kelly Yancey" writes: > > > Ahh...but wouldn't the bzero() touch all of the memory just > > > allocated functionally making it non-overcommit? > > > > No. If it were an "non-overcomitting malloc", it would return NULL > > and set errno to ENOMEM, instead of dumping core. > > It should be possible to modify calloc to trap signals, then bzero. If > bzero faults, you free the memory and return NULL. > > No, wait. You can't trap SIGKILL. How about this. mmap() some > anonymous memory MAP_SHARED, fork a child to bzero it. If the child > dies, unmmap and return NULL. If the child succeeds, use the memory. > This memory won't be freeable with malloc(), though. > Hrm. I'm not actually trying to get my system to not overcommit memory. I like overcommit. Besides, every process would have to trap SIGKILL (if you even could) to simulate a non-overcommit system because any process could be killed, not just the one requesting the memory, right? Really, I was just on an educational quest. I was curious to exactly how calloc() was implemented and what affect that had on our overcommit policy. DES was nice enough to show me that calloc() is just a malloc()+bzero() so effectively, the memory gets 'committed' because all of the pages are touched immediately after the malloc(). Whether or not a process get's shot is another matter entirely. :) I have another post on this list which begs the question: if memory given to us fro sbrk() is already zeroed, why zero it again if we don't have too if we make calloc() smarter, we could save come clock cycles. The real question is, how many? A quick scan (not exact) of the number of times calloc() is called yields: $ cd /usr/src $ t=0; grep -c -h -R "calloc" * | while read n; do let t+=$n; echo $t; done | tail -1 828 $ t=0; grep -c -h -R "malloc" * | while read n; do let t+=$n; echo $t; done | tail -1 11380 (of course, they each are a little high due to comments and the actual function definitions themselves; cavaet emptor) So calloc() is only used about 1/14th as often as malloc(), and considering many of those calloc() calls would still be serviced the same was a malloc() (reusing memory already on the heap and bzero()'ing it), I'm not 100% sure if the added complexity if worth the performance improvement. If it is, I'de be glad to "whip" some patches up for it (it really shouldn't be too hard). Kelly ~kby...@posi.net~ FreeBSD - The Power To Serve - http://www.freebsd.org/ Join Team FreeBSD - http://www.posi.net/freebsd/Team-FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
RE: Overcommit and calloc()
From: Kelly Yancey [mailto:kby...@alcnet.com] >I have another post on this list which begs the question: if memory given >to us fro sbrk() is already zeroed, why zero it again if we don't have >too if we make calloc() smarter, we could save come clock cycles. Because the memory returned from malloc() might be from a previous malloc()/free() and may be dirty. Charles To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD, and userfs too.
> > Lovely. Sounds like a much better way to do the Solaris/Linux (and > > NetBSD?) /etc/nsswitch.conf stuff. On Solaris at least, this is > > implemented using masses of weird shared objects... > >The plan for NetBSD is that things will also be handled with dynamic >modules, but those dynamic modules will be glued into a `nscd'[*] (if you >use Solaris, you're familiar with the name :-). > >[*] We are planning on not having all of the problems that the Solaris >nscd has, and that people often complain about. > >This will allow libc to simply make a call to nscd (or fallback onto >traditional `files' lookup), and nscd will handle all but the `files' >case. This allows system-wide caching, and puts all of the complexity >in one place. > >Involving one or more user mode file systems seems like ... the wrong >approach for a name service switch. Tomato, Tomatoe. The difference between the 2 methods is in their interaction with the database itself. You will be providing a socket-ish interface to the cache, my plan is for a filesystem interface, heck it could probably do both. I personally prefer the FS approach in dealing with both on Solaris and Irix. What Irix does well, Irix does very well. The FS method also allows more complex permission checking on access to various databases, like shadow, because the node in a directory had the added granularity of being group readable. It also gives you the flexibility of the shell, or a web-browser, to get at the data. Another idea I had considered was placing something ala 'rc.conf' into a database to allow easy distribution throughout many computers (this would obviously be configuration later in the boot process). Having a FS style interface makes it much easier for programs to get at the data in a clear, consistent manor. These are just my ramblinngs, and it seems we are quickly converging on the same basic idea with slightly different (but perhaps compatible) implementations. -- David Cross | email: cro...@cs.rpi.edu Systems Administrator/Research Programmer | Web: http://www.cs.rpi.edu/~crossd Rensselaer Polytechnic Institute, | Ph: 518.276.2860 Department of Computer Science| Fax: 518.276.4033 I speak only for myself. | WinNT:Linux::Linux:FreeBSD To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
speed of file(1)
While trying to port amavis, the virusscanner for mail, http://aachalon.de/AMaViS/amavis-0.2.0-pre4.tar.gz ) I noticed it used the file(1) several times for each file, and it took rather long time, causing bb to report red for high CPU-load each time I collected a batch of mail. So I compared it with a Linux box: My 60MHz Pentium, FreeBSD time file /usr/home/leif/vnc-3.3.2r /usr/home/leif/vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated, original filename, last modified: Thu Jan 21 19:23:21 1999 real0m1.237s user0m0.758s sys 0m0.394s 133MHz Pentium II, Linux time file vnc-3.3.2r3_unixsrc.tgz vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated, original filename, last modified: Thu Jan 21 19:23:21 1999, os: Unix real0m0.036s user0m0.010s sys 0m0.030s While I realise 60MHz is less than 133MHz, a factor 34 in difference of real time seems suspect. The magic file is different, but almost the same size. Why is FreeBSD's file so much slower? Leif To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: RE: Overcommit and calloc()
:From: Kelly Yancey [mailto:kby...@alcnet.com] :>I have another post on this list which begs the question: if memory given :>to us fro sbrk() is already zeroed, why zero it again if we don't have :>too if we make calloc() smarter, we could save come clock cycles. : :Because the memory returned from malloc() might be from a previous :malloc()/free() and may be dirty. : :Charles malloc() uses madvise( ... MADV_FREE) heavily in order to reduce the number of page faults that need to be taken through the course of a program's operation. MADV_FREE is an advisory free that causes FreeBSD to mark the underlying page(s) clean and to free any associated swap backing store. The kernel avoids actually freeing the page until it needs the memory, and the process can re-dirty the page to keep it. No new page-faults occur if the kernel has not reclaimed the page at the time the process reuses it. If the kernel reclaims the page first, the kernel replaces it with zero-fill. If the process reclaims the page first, the page's previous contents (considered to be 'garbage') are retained. Thus, calloc() cannot under normal circumstances assume that the data buffer returned by malloc() is already clear. Since calloc() is not usually used to allocate large chunks of memory, this isn't a problem. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Mon, 19 Jul 1999, Reinier Bezuidenhout wrote: > Hi .. > > > > 1. If you want to test the network speed ... use ttcp or something > > >that generates the data and doesn't read it from disk. > > > > ttcp works. The only problem is when I tried it in both > > directions, at once. the total becomes 11.xMbytes/sec total as opposed to > > 9.4Mbytes/sec when doing it in one direction only. > > If the devices are set at full-duplex then you are looking at something > else ... the standard size for ttcp packets is 8k ... maybe the switch > etc. that you are connected to doesn't handle fragmented packets very well. Hmmm, the thing is we replaced the cables with pre-made ones that go directly from the machines to the Cisco Catalyst 2924XL switch. Ofcourse, the switch is on 10/100 Auto-negotiation. > But ... what it rather seems like .. is that the devices are not in > full-duplex mode generating a lot of collisions. After a test > with transfers in both directions .. check the number of collisions > with "netstat -in". If the number of collisions is not high .. - wait > a moment ... are you using ttcp with tcp or udp option ... if you are > using tcp (the default) then when transfering data you have acks going > in both directions which could cause collisions on a full-duplex line ... > try the same with the -u option for UDP. Check our setup below ... > I'll explain some things there. I was using ttcp in two separate instances, one for send and one for receive between the same two machines. I did ttcp -r -s and the other end was ttcp -s -r. > Also check with "netstat -sn" to see if there are any other counters that > increase with the full-duplex transfers. Will do that. > > > 2. When doing full-duplex and using fxp cards, stay away from X-over > > >cables ... use a full-duplex switch etc. ... the fxp cards are not > > >made to work with X-over cables (as far as I know - ala Intel spec) > > >note ... only for full-duplex tests. > > > > Does anyone actually use X-over cables for 100Mbps Full Duplex > > since 3Com said CrossOver cables are not rated for 100Mbps or something > > even though it's Cat5. Actually, in the older Intel docs for the Pro100B, > > it does say to connect using X-over cable to the switch. > > Yes ... to a switch maybe ... but not fxp to fxp ... when transfering > small packets .. you get a lot of "device timeouts". I thought from a fxp to a fxp, you will need a x-over since a straight-wire won't work. > > > We have done tests in full-duplex with non Intel cards (because we did > > > not have a switch at that time :)) and with max size packets we got around > > > 188.00 Mbps using the de0 driver. > > > > Pretty interesting. How did you do the full duplex tests? > > I'll describe the setup briefly ... :) > > We had 3 machines two PII-400 as the generators and a PII-400 as the > machine in the middle ... > > So we have a setup that looks like this ... > > >- -- - >| Gen 1 |-| Router |-| Gen 2 | >- -- - > > Now .. here is a trick ... add entries manually in the Router's tables > to simulate machines on each side that "does not exist". The reason > for this is that we don't want the machines on the side to be generating > AND excepting packets ... we just want them to generate packets at max > network rate and nothing else. > > We then start a ttcp on both sides to the "non existing" machines. This > means the router will be forwaring packets it receives without any > machines having to be there because of the entries in the routing table. > (we did this because we did not have another two fast machines at that > time, but we did check the packets to make sure everything goes through > and are not dropped etc. - it was some time ago :) ) > > We start ttcp with the following command > > ttcp -t -s -u -p 7000 -n -l 1472 10.0.0.1 > > the size of 1472 generates nice 1514 size UDP packets :) > > We then let the test run ... and check the throughput ... > > We used CAT5 X-over cables ... > > Hopw this helps Ah, I guess you didn't test it on a actual network that's connected to the world and also it was a direct connection between the machines rather than through a switch that can be congested. Cheers, Vince - vi...@mcestate.com - vi...@gaianet.net __ Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / |[__ ] GaiaNet Corporation - M & C Estate / / / / | / | __] ] Beverly Hills, California USA 90210 / / / / / |/ / | __] ] HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: speed of file(1)
Check the size of the magic files on your FreeBSD and Linux boxen. file was never really designed to be efficient. FreeBSD's magic file is /usr/share/misc/magic - around 164K. -Matt : :While trying to port amavis, the virusscanner for mail, : http://aachalon.de/AMaViS/amavis-0.2.0-pre4.tar.gz ) I noticed it used the :file(1) several times for each file, and it took rather long time, causing :bb to report red for high CPU-load each time I collected a batch of mail. : :So I compared it with a Linux box: : :My 60MHz Pentium, FreeBSD : :time file /usr/home/leif/vnc-3.3.2r :/usr/home/leif/vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated, :original filename, last modified: Thu Jan 21 19:23:21 1999 : :real0m1.237s :user0m0.758s :sys 0m0.394s : :133MHz Pentium II, Linux : :time file vnc-3.3.2r3_unixsrc.tgz :vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated, original filename, :last modified: Thu Jan 21 19:23:21 1999, os: Unix : :real0m0.036s :user0m0.010s :sys 0m0.030s : :While I realise 60MHz is less than 133MHz, a factor 34 in difference of real :time seems suspect. : :The magic file is different, but almost the same size. : :Why is FreeBSD's file so much slower? : :Leif : : : : :To Unsubscribe: send mail to majord...@freebsd.org :with "unsubscribe freebsd-hackers" in the body of the message : Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Anything special with kmem_map and mb_map?
:I have been wondering this for some time. There are many kernel :submaps: exec_map, clean_map, :etc. But if you look the code in vm_map_find(), we have to call splvm() :for kmem_map and its :submap mb_map, but not for other kernel submaps. So is there anything :special with these two :kernel submaps? : :Thanks for any help. : :-Zhihui The kmem_map and mb_map's can be modified from interrupts. The other maps cannot. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Simple parallel debugger
If you have needed to monitor and control lots of processes on e.g. a cluster I have rereleased a tool for this purpose. It is called simple parallel debugger, or SPD. Please if interested go to www.acl.lanl.gov/~rminnich and follow the link under that title. I know this is a bit old but I have yet to see a counterpart elsewhere that is freely available. Comments, questions, suggestions are most welcome. Thanks ron To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: Determining the return address
Dag-Erling Smorgrav wrote: >Alfred Perlstein writes: >> specifically how you say you increment it, then decrement it, >> if you have multiple handlers where one can interupt another >> you can have the counter get jumbled. > >Not if increment / decrement is atomic. Which it _isn't_ in general. The only case where it _is_ atomic is on a UP i386, where the compiler has generated an `inc' instruction (which it might not). Check out /sys/alpha/include/atomic.h or a recent (less than a week old [1]) -current version of /sys/i386/include/atomic.h for atomic code. Peter [1] It was broken prior to this. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
> > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com > > > > > > > > Horrible idea. > > > > > > > > > > suggestions? > > > > Use PAM. > > PAM isn't going to cut it. This is outside of its realm. Things like ps, > top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able > to pull 'passwd' entries from the LDAP server, and unless we PAM all of those > (I think that is a very bad idea), then a person will be able to login but > will be dead in the water without a UID <->Username mapping. The Linux-PAM folks solved this with their 'libpwdb', which basically provides a transport-neutral interface to the whole uid:userdata mapping. Unfortunately, their implementation _reeks_, so nobody has touched it yet. This is, however, how I think we should be going. -- \\ 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
Sv: speed of file(1)
From: Matthew Dillon > Check the size of the magic files on your FreeBSD and Linux boxen. > file was never really designed to be efficient. FreeBSD's magic > file is /usr/share/misc/magic - around 164K. > > -Matt > > : > > : > :The magic file is different, but almost the same size. > : Leif To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
Keith Stevenson wrote: > > On Mon, Jul 19, 1999 at 06:22:17PM +0200, Dag-Erling Smorgrav wrote: > > Oscar Bonilla writes: > > > On Mon, Jul 19, 1999 at 06:13:51PM +0200, Dag-Erling Smorgrav wrote: > > > > Oscar Bonilla writes: > > > > > the idea is to have an entry in the /etc/passwd enabling LDAP lookups. > > > > > the Entry would be of the form > > > > > > > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com > > > > Horrible idea. > > > suggestions? > > > > /etc/auth.conf > > > > Given that this is a PAM module, wouldn't /etc/pam.conf be more appropriate? /etc/pam.conf would be appropriate for configuring the behavior of PAM modules. /etc/auth.conf would be appropriate for configuring WHICH authentication method to use. Let's please don't confuse the two. -- "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: PAM & LDAP in FreeBSD
On Fri, Jul 16, 1999 at 12:36:48PM -0600, Oscar Bonilla wrote: > For LDAP to be seamlessly integrated into the system some of the libraries > have to be changed. Specifically the ones dealing with /etc/passwd and > user information. <...> I haven't seen him post to this thread yet, but you might want to talk to Amancio Hasty . I know he's been working with LDAP and FreeBSD. 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
m68k Support in FreeBSD
A week or so ago there was some discussion of someone who ported FreeBSD to 68k-based Macintosh systems on EFNet. There was also a reference to a 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? :) Jamie To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
Mike Smith wrote: > > > > > > > ldap:*:389:389:o=My Organization, c=BR:uid:ldap.myorg.com > > > > > > > > > > Horrible idea. > > > > > > > > > > > > > suggestions? > > > > > > Use PAM. > > > > PAM isn't going to cut it. This is outside of its realm. Things like ps, > > top, ls, chown, chmod, lpr, rcmd, who, w, (the list goes on) need to be able > > to pull 'passwd' entries from the LDAP server, and unless we PAM all of > > those > > (I think that is a very bad idea), then a person will be able to login but > > will be dead in the water without a UID <->Username mapping. > > The Linux-PAM folks solved this with their 'libpwdb', which basically > provides a transport-neutral interface to the whole uid:userdata > mapping. Unfortunately, their implementation _reeks_, so nobody has > touched it yet. > > This is, however, how I think we should be going. 100% agreement here. This needs to be implemented such that the administrator configures the box to use local files, or NIS, or LDAP, or whatever as the source of username information, and both login(1) and ls(1) use the information as appropriate. For ls(1) and friends, this means implementing getpwuid(3) (and getgrgid(3)) so they "just work." The implementation details are as unimportant as ever: they have to work and be maintainable. Following prior art remains a good idea; the Solaris "name service switch" implementation is a good starting point to consider. -- "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: How much memory do we need to install?
On Mon, Jul 19, 1999 at 05:34:07PM +0930, Greg Lehey wrote: > AFAIK, the minimum memory for installation is still 5 MB, and the > problems people had with 8MB machines failing to install was a bug, > right? What's the current status? Some people have reported that they need up to 12MB to install. -- This is my .signature which gets appended to the end of my messages. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: speed of file(1)
Matthew Dillon wrote: > > Check the size of the magic files on your FreeBSD and Linux boxen. > file was never really designed to be efficient. FreeBSD's magic > file is /usr/share/misc/magic - around 164K. The Linux one 169350 bytes, 4891 lines. The FreeBSD 3.1 magic file is 164223 bytes, 4802 lines. > Leif Neland asked: > > :While trying to port amavis, the virusscanner for mail, > : http://aachalon.de/AMaViS/amavis-0.2.0-pre4.tar.gz ) I noticed it used the > :file(1) several times for each file, and it took rather long time, causing This begs the question "Why?" Can't the program cache the results of file(1) instead of calling it multiple times? Premature optimization is the root of all evil. -- "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
maxfiles == maxfilesperproc ?
hax0rs, In sys/conf/param.c (in -STABLE), both maxfiles and maxfilesperproc are set equal to MAXFILES. This doesn't make much sense to me. It seems that maxfiles should be set to be greater than maxfilesperproc by default, so that one process can't consume all of the file descriptors. I noticed this while building a system that will be running some very large processes with many open files, so set maxfilesperproc on that box equal to MAXFILES - 512, but this metric is not appropriate for systems with small MAXUSERS (like GENERIC). So... 1. Should maxfiles be, by default, larger than maxfilesperproc? 2. If so, how much is necessary and appropriate? Regards, Greg -- Gregory S. Sutter "How do I read this file?" mailto:gsut...@pobox.com"You uudecode it." http://www.pobox.com/~gsutter/ "I I I decode it?" PGP DSS public key 0x40AE3052 To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: maxfiles == maxfilesperproc ?
> hax0rs, > > In sys/conf/param.c (in -STABLE), both maxfiles and maxfilesperproc are > set equal to MAXFILES. This doesn't make much sense to me. It seems that > maxfiles should be set to be greater than maxfilesperproc by default, so > that one process can't consume all of the file descriptors. > > I noticed this while building a system that will be running some very > large processes with many open files, so set maxfilesperproc on that box > equal to MAXFILES - 512, but this metric is not appropriate for systems > with small MAXUSERS (like GENERIC). So... > > 1. Should maxfiles be, by default, larger than maxfilesperproc? Not really; these numbers are just ultra-hard limits. You should typically use login classes and the per-process limits to enforce these controls. -- \\ 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: m68k Support in FreeBSD
> 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. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: m68k Support in FreeBSD
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. Isn't it more a question of whether a proper cross-build system will be available within the time frame that m68ks aren't completely obsolete? > > - Jordan > > > 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: m68k Support in FreeBSD
> 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. > > Isn't it more a question of whether a proper cross-build system will > be available within the time frame that m68ks aren't completely obsolete? No. - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: m68k Support in FreeBSD
On Mon, 19 Jul 1999, Brian F. Feldman wrote: > On Mon, 19 Jul 1999, Jordan K. Hubbard wrote: > > > 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. > > Isn't it more a question of whether a proper cross-build system will > be available within the time frame that m68ks aren't completely obsolete? > Hey wait a second! I have a wonderful HP Apollo 400 Series with a 68030 at 50MHz that is so impressive looking friends and family stare in awe at it.:) Seriously, it runs NetBSD, and is a great xterm (19" black and white monitor). I assume mac's and amigas with m68k's are just as useful. -- Kyle Mestery| StorageTek's Storage Networking Group mest...@visi.com| http://www.freebsd.org/ mest...@netwinder.org | http://www.netwinder.org/ Protect your right to privacy: www.freecrypto.org To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
PAO
NB: Please reply to me directly, I'm not on the list pertinent data: FreeBSD 3.2R on a SONY VAIO laptop, PAO3-19990605 version I just installed PAO on my SONY VAIO in hopes of getting my 3COM 3CXE589ET PCMCIA eithernet card working. When I boot the laptop with the PAO install floppies it finds the card and it works because I was able to download the PAO distributions from the FTP site through it. However when I reboot the system after the install I get the following errors. - - - Initial rc.pccard configuration: pcic-memory=0xd pccardc: /dev/card0: Device not configured execute pccardd pccard-beep=2 pccardc: /dev/card0: Device not configured . Doinf initial network setup: hostname. ifconfig: interface ep0 does not exist ifconfig: interface ep0 does not exist lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 route: writing to routing socket: Network is unreachable - - - Typical startup stuff follows then syslogd pukes with the error. syslogd: syslog/udp: unknown service syslogd: child pid 107 exited with return code 1 I'm sure I've missed somthing stupid but I can see it. I can get a 3com 3c589 as listed in the release notes as a last resort. Does anybody have one of these working? thanks in advance for any help. -- Geoffrey Robinson To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sat, 17 Jul 1999, Vincent Poy wrote: > > > By reading the man page? > > The manpage doesn't really say anything about how to use ttcp... I don't think manpage useage is -hackers-esque. > There is no ttcp binary anywhere on either my -CURRENT, > 3.2-RELEASE and 3.1-RELEASE systems. Ever hear of ports? Or is 'how to use the ports collection' suddenly -hackers material? That, and .sig files that contain more relevant bits than the sender's posts... Oh, and I'd appreciate it if you could refrain from quoting this entire message to simply say, 'Interesting'... Thanks. Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAO
In article <3793dad7.67fba...@click2net.com> ge...@click2net.com writes: >> pertinent data: FreeBSD 3.2R on a SONY VAIO laptop, PAO3-19990605 >> version >> >> I just installed PAO on my SONY VAIO in hopes of getting my 3COM >> 3CXE589ET PCMCIA eithernet card working. When I boot the laptop with the >> PAO install floppies it finds the card and it works because I was able >> to download the PAO distributions from the FTP site through it. However >> when I reboot the system after the install I get the following errors. Maybe your kernel is still GENERIC kernel. Please try # cd / # chflags noschg kernel # cp kernel.PAO kernel # chflags schg kernel and reboot. If there's not kernel.PAO file, paobin has not successfly installed yet. -- HOSOKAWA, Tatsumi Assistant Manager Information Technology Center, Keio University To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: poor ethernet performance?
On Sun, 18 Jul 1999, Vincent Poy wrote: > I'm not sure if it shows the mac address of the cisco's port or > the actual device connected to it... You see the MAC of the switch's port. It's been too long since I've played on a Catalyst... but what does 'sh arp' display? Any arp -> port -> host correlations? Good luck... :) > That's a option too... Only problem is that can take forever. :-) Yeah, I've noticed the 'sync-up time' takes quite awhile on a Catalyst running 100Mbps. Later, --mike To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Mon, 19 Jul 1999, Wes Peters wrote: > > Given that this is a PAM module, wouldn't /etc/pam.conf be more appropriate? > > /etc/pam.conf would be appropriate for configuring the behavior of PAM > modules. /etc/auth.conf would be appropriate for configuring WHICH > authentication method to use. Let's please don't confuse the two. In my work on modularizing crypt() (which is almost ready for another alpha release) I'm using login classes in /etc/login.conf instead of system-global settings in /etc/auth.conf to decide password hash schemes. Kris To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: speed of file(1)
: :The Linux one 169350 bytes, 4891 lines. The FreeBSD 3.1 magic file is :164223 bytes, 4802 lines. : :> Leif Neland asked: :> :> :While trying to port amavis, the virusscanner for mail, :> : http://aachalon.de/AMaViS/amavis-0.2.0-pre4.tar.gz ) I noticed it used the :> :file(1) several times for each file, and it took rather long time, causing : :This begs the question "Why?" Can't the program cache the results of file(1) :instead of calling it multiple times? : :Premature optimization is the root of all evil. : : :-- :"Where am I, and what am I doing in this handbasket?" : :Wes Peters Softweyr LLC :http://softweyr.com/ w...@softweyr.com Someone would have to compare file sources or profile it to figure out what is causing the slowness. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM & LDAP in FreeBSD
On Mon, Jul 19, 1999 at 04:51:12PM -0600, Wes Peters wrote: > The implementation details are as unimportant as ever: they have to work > and be maintainable. Following prior art remains a good idea; the Solaris > "name service switch" implementation is a good starting point to consider. > I agree. In solaris (and linux by the way) all you do is set passwd ldap files in /etc/nsswitch.conf and that's it. I had started to write the code to mess with libc to "fix" the getpwent stuff, but a better solution is to "port" the nsswitch stuff from linux (i don't have source from solaris :) Anyone more knowledgeable should give me a big hand here and point me to the right way to start this. I'm willing to do the coding but need help on the overall design. Since I need this working asap, I'm gonna hack libc so that if the file /etc/auth.conf has a line saying auth_list = ldap, it looks in /etc/ldap.conf to get the rest of the stuff (server, port, base dn, etc). At the same time, we should work towards a real solution. regards, -Oscar -- For PGP Public Key: finger oboni...@fisicc-ufm.edu To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-hackers" in the body of the message
Re: m68k Support in FreeBSD
On Mon, 19 Jul 1999, Brian F. Feldman wrote: > Isn't it more a question of whether a proper cross-build system will > be available within the time frame that m68ks aren't completely obsolete? Bah! An 040 or 030 powered Mac w/ MacOS makes a decent web browsing, word processing machine; it's an actually useable alternative to an e-machine. Similarlly a 386 or 486 powered FreeBSD machine can still be quite useful even as a small server (admittedly the 68k Mac hardware makes for a piss poor server.. but still). I can't see a 486 or 040 powered machine becomming entirely obsolete until X is required to buildworld. - 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
