Re: FreeBSD locations (was: Pictures from USENIX)
Greg Lehey wrote: John Birrell's further South (Melbourne, for a first approximation): -37.7144.9jb Close enough. Danny O'Callaghan (danny) and Peter Hawkins (thpish) are in Melbourne too. -- John Birrell - [EMAIL PROTECTED]; [EMAIL PROTECTED] http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
For your information http://www.mapblast.com specifies LongLat at the bottom of the page when you are looking at a map. Just move the icon to the right place. Cheers Nick n_hibma[ Icon Latitude: 45.869154, Longitude: 8.620118 ] On Mon, 5 Jul 1999, Wes Peters wrote: Tim Vanderhoek wrote: On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? Here's what I have so far: # # Walnut Creek, our good friends. # 37.91 -122.06 "Walnut Creek" # Walnut Creek CD-ROM # # FreeBSD core team members # 37.9, -122.3, "asami" # Berkeley, CA ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? Here's what I have so far: 55.4, 11.3, "phk, sos" # Denmark That should be: 55.4, 11.3, "phk" # Denmark 57.2, 10.2, "sos" # Denmark We dont live THAT close together :) Or rather, they live on opposite ends of the country ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
In message [EMAIL PROTECTED] Bill Fumerola writes: : It also clears up the misconception that being a member of -core requires : a beard. If it did, then Jordan would be out. :-) Justin too. Those are the only two core members that I can even recall what they looked like... I don't think I've ever seen a 5 O'clock shadow on Justin... Certainly not on a regular basis. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
In message [EMAIL PROTECTED] Wes Peters writes: : 40.1, -105.3, "gibbs, wosh" # Boulder, CO (wow!) wosh? Didn't know there was a wosh in core. It certainly isn't me, since I'm in Boulder, but not in core. There appears to be no wosh account on freefall. : 40.1-105.3 " , merry, passe" # Boulder, CO (wow!) Warner Losh, Ken Merry, Steve Passe and (until recently) Sean Kelly. Boulder is a small town, since I used to work with Ken, Sean and Justin. I now work with Steve Passe : largest concentration so far is Boulder Colorado with 4, followed by Yes. And if those are the only committers, their places of employment are separated by only a few blocks (literally walking distance, I've made the walk before when I was at Pluto since my wife works across the street from Timing Solutions) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
In message Pine.GSO.3.95q.990705091442.676N-10@elect8 Nick Hibma writes: : For your information : http://www.mapblast.com : specifies LongLat at the bottom of the page when you are looking at a : map. Just move the icon to the right place. That puts my current employer at 40.029322, -105.227900 and Pluto at 40.023712, -105.225382. Well, I'd have to knock a couple of significant figures off those since the addresses for these two places don't quite match the icon on the map... I told you they were walking distance... :-) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Porting LILO to FreeBSD
Warner Losh wrote: In message [EMAIL PROTECTED] Adrian Filipi-Martin writes: : The standard boot partition selection softwre also works fine : booting windoze OS's from other disks. All you need to do is set the "disk : id" in the DOS MBR to the correct number, 0x81 for your second disk. That's : the only thing that MS doesn't do correctly whe installing the OS on the : non-primary disk. I used to do this a long time ago to boot FreeBSD of the : "C" drive and the other stuff off of "second C" drive. How does one do that? What tools do you use? I did this, using an old copy of Norton Disk Edit. It didn't work, although it did do something. Before I did it, if I told os-bs beta to boot DOS, it would give a `non-system disk or disk error' message (if I recall correctly; if not, it simply hung with no message). After changing the disk ID, it got as far as `Starting MS-DOS' but hung at that point. Note that os-bs beta was not good enough on its own. Actually, come to think of it, I didn't quite do this - I changed the disk ID in the boot sector of the DOS partition, rather than the MBR. Given that you do this with Norton Disk Editor, do you have to run DE and tweak it every time you want to change the disk? I guess one could write progs that runs under either O/S that will just toggle the appropriate byte, making it a bit less convenient. It's still a bit of a drag if you want to boot one O/S and the other is enabled, and you're powering up - you have to boot the wrong one, toggle the byte, and then reboot. I subsequently gave up and tried to uninstall os-bs beta. It told me that the uninstall option was not available. So I used Norton Disk Editor to restore my LILO boot record - except I mistakenly specified a logical rather than a physical sector. I spent the next day recovering from this (to the point where I had the screwdrivers out!). I gave myself a hundred lines: I will not confuse the physical and the logical; I will not confuse the physical and the logical... In the end I was back to square one. But then I remembered the real reason I had such a screwy setup - not for DOS itself, but because I wanted Windoze 3.1. But I haven't actually needed it in about two years, so I installed os-bs 3.5, scrapped the \Linux directory on my C: drive, and I'm quite happy (I can still boot DOS 6.2 from Win 95 by pressing F8 and selecting `Boot previous version of MS-DOS'). I still think it would be a good thing to port LILO to FreeBSD (and/or DOS/Windoze for that matter), but I'll leave that for another time (or another person!) -- Dr Graham Wheeler E-mail: [EMAIL PROTECTED] Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security Specialists WWW: http://www.cequrux.com/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Login.conf (Whose problem is this) ?
On Sat, 03 Jul 1999 18:57:06 MST, John Polstra wrote: This stuff is old and obsolete. LOGIN_CAP_AUTH isn't supported any more. (It never was fully supported, actually.) Don't use it. There's an open PR for this, PR 10115. I assume all that's required is that we smack the outdated comments from login.conf? Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Dynamic linking
Hi everyone! Is there a way of making dlopen return an error from the shared object's _init function? Thanks. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() scalability
Also, you really want to return more than one event at at time in order to amortize the cost of the system call over several events, this doesn't seem possible with callbacks (or upcalls). yes, that would be a nice behaviour, but I haven't seen it become a real issue yet. the sigwaitinfo() syscall is just so much lighter than all the other things going on in the situation where you actually use this system. How about a modified sigwaitinfo that will return a number of waiting siginfo -- of course this introduces the problem of deciding how long to wait for new additions to the queue before returning. This is something similar to the Nagle algorithm.. Or perhaps sigwaitinfo could buffer siginfo's in user space, although this introduces complexity if you want the ability to cancel queued signals... Regards, Niall To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD locations (was: Pictures from USENIX)
Greg Lehey wrote: On Monday, 5 July 1999 at 0:12:55 -0600, Wes Peters wrote: [..] -31.58,115.49, "peter" # Perth, Australia. Peter's gone to the USA, we think. Not yet. Not till later this year. Cheers, -Peter To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Dynamic linking
- jir ji jimaria [EMAIL PROTECTED] irc#tokyo15 icq jir 3941247- http://www.enjoynight.com/cgi-bin/friends/ji/familychat.cgi VAIO@PCG-C1@e arcQQW Hi everyone! Is there a way of making dlopen return an error from the shared object's _init function? Thanks. What matters? May you instool some windows'soft? and change *.dll file serch *.dll and *is err's *dll You got? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() scalability
How about a modified sigwaitinfo that will return a number of waiting siginfo -- of course this introduces the problem of deciding how long to wait for new additions to the queue before returning. This is you'd just have a 'give me up to X' parameter, if you get a single one under high load they will queue up until you call it next time.. waiting around stinks, these operations usually want low latency. could buffer siginfo's in user space, although this introduces complexity if you want the ability to cancel queued signals... yes, that is the hard part :) -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
On Mon, 5 Jul 1999, Greg Lehey wrote: It also clears up the misconception that being a member of -core requires a beard. A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Nothing. I just remember someone pointing out in a previous e-mail that all the core members had some sort of beard. - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repalcement for grep(1)
Jamie Howard writes: Perhaps this will help with -w? Yes, I received a patch from Simon Burge which implements this. It also beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. I am still having trouble with -x though. It turns out that even if I specify a commandline with a pattern of the form "^pattern$", it fails. If I specify "^pattern" it works. If I specify "pattern$" it does not. I have yet to find a case where my version will sucessfully match when a $ is at the end. Has anyone encountered anything like this before? Are you sure you're stripping out the newline and carriage return? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
re: 'rtfm script'
I'm in favor of the rtfm script. It's amazing the positive things that come out of an offhand IRC comment. [ from http://www.emsphone.com/FreeBSD/log.cgi/19990704.txt ] [15:29] billf tribune: yes, RTFM. [15:29] billf we need rtfm(1) [15:30] billf rtfm(1) would search the man pages, FAQ, and handbook for the COMPLETLY clueless. [15:31] cmc billf: that rtfm command, I might write one. maybe it'll get people to shut the hell up ;) [15:32] cmc It'd be easy to do in Perl. [15:32] billf cmc: I'd import it for you. [15:32] sysctl rtfm would work good.. in perl even [15:32] sysctl have it translate between "rtfm subject" and "rtfm subject(1)" [15:33] cmc First it'll search the man pages. Then the handbook. Then the FAQ. Then, maybe see if I can find out if they start bitching, and if so, email Jesus Monroy. At that point the converstaion turned to talking about Irish soap carving and the fact that www.OpenBSD.org doesn't run OpenBSD. I guess I was wrong about IRC being positive. - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD locations (was: Pictures from USENIX)
Greg Lehey wrote: On Monday, 5 July 1999 at 0:12:55 -0600, Wes Peters wrote: Here's what I have so far: 52.0, 13.8, "joerg" # Germany You've put Jörg somewhere near Berlin. He's in Dresden, further to the South-East. That's what he mailed me. I can't find a map of Dresden with lat- long right now. Help? -31.58,115.49, "peter" # Perth, Australia. Peter's gone to the USA, we think. Not another one? The FreeBSD Aussie invasion continues... -34.53 138.35 "newton, kris, grog" # Adelaide, SA Australia I'm not in Adelaide, remember? Here are my coordinates: -35.14 138.77 grog You didn't respond, so I lumped you in with the Adelaid crowd. I knew you were south of Adelaide, but I couldn't find Echunga on the only map I could find that gave coordinates. So far, Eivind is the northernmost and Grog and the Adelaide crowd the southernmost. John Birrell's further South (Melbourne, for a first approximation): -37.7144.9 jb BDE is the easternmost and Jordan the westernmost. The largest concentration so far is Boulder Colorado with 4, followed by the Adelaide gang with 3. Hmm. Doesn't Daniel O'Connor have commit privileges? And it's time for Mike Smith to come home, then we'd have 5 :-) Oh lord, are we going to have to rename ourselves OzBSD now? ;^) Daniel doesn't have an account on freefall. -- "Where am I, and what am I doing in this handbasket?" ` Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
mouse/keyboard usage statistics...
Hi, just as a curiosity (or maybe not...) i was wondering what would be the easiest way to get rough estimate of the number of keypress and mouse movements i do. It appears that vmstat -i already gives some estimate for the keyboard, e.g. ordinary keys give a couple of interrupts (on press/release), but whenever the autorepeat starts I get some 18 int/s and thus the data is extremely noisy. Is there a way to get 'true' keypress counts in the "sc" driver, and especially log this info into syslog when the system is shut down ? Same problems for mouse movements, except perhaps that i can hook into moused and so the problem is a little bit easier to deal with. cheers luigi ---+- Luigi RIZZO, [EMAIL PROTECTED] . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm script'
On Mon, Jul 5, 1999, Bill Fumerola wrote: I'm in favor of the rtfm script. It's amazing the positive things that come out of an offhand IRC comment. [ from http://www.emsphone.com/FreeBSD/log.cgi/19990704.txt ] [15:33] cmc First it'll search the man pages. Then the handbook. Then the FAQ. Then, maybe see if I can find out if they start bitching, and if so, email Jesus Monroy. Note that I can't figure out a decent way to search the Handbook at this point, but I'm open to ideas. -- Chris Costello[EMAIL PROTECTED] Stack Error: Lost on a cluttered desk... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: poll() scalability
On Jul 07, 1999 at 01:10:38AM -0400, Zach Brown wrote: the sigio/siginfo model is a few orders of magnitude cheaper than poll/select as you scale the number of fds you're watching. The reasons for this being that select()/poll() have that large chunk of state to throw around every syscall, and the real world behaviour of very rarely ever returning more than than a few active pollfds Yes; that's effectively what the "delta" method I'm using now gets rid of; it only passes around state changes instead of the entire state. I agree that passing around the entire state is quite un-efficient; that's what I would like to get rid of. We just need to agree on a new method. with the sigio/siginfo model you register your interest in the fd at fd creation. from then on, when a POLL_ event happens on the fd we notice that it has an rt signal queue registered and a siginfo struct is tacked onto the end. these code paths can be nice and light. the siginfo enqueueing can be pointed at multiple queues by registering a process group with F_SETOWN, etc. Yes, but I also need support for temporarily "de-registering" interest in an fd, as well selectively choosing read/write/close events. its important to notice that we don't actually use signal delivery for this sigio/siginfo stuff, we mask the signal and use signwaitinfo() to block or pop the next siginfo struct off the queue. dealing with async signals jumping in would be annoying, and to do it right one would probably want to simply enqueue the siginfo delivered to the signal handler into a nice fifo that the real thread of execution would deal with.. instead of doing all this grossness, we just let the kernel maintain the siginfo queue. In this case, it doesn't seem all that different than a poll() type call, or an event queue that Peter was talking about. If the signal is blocked, then sigwaitinfo() effectively becomes a poll(), but with no timeout parameter. its quite like the 'delta poll' system proposed, but with differently inelegant semantics. I'd say if one were to design an event queueing/notification system and add a new api for it, we'd want to do it correctly from the get-go and lose the similarity to existing interfaces entirely unless they really makes sense to behave like them (which it doesn't in the poll() case, imho) I agree. One aspect of the design that should be explored is whether the new call should report "events", or "state". My current implementation reports state; (think of it as a level-triggered design), while the siginfo approach appears to be more of an "edge-triggered" design. I just looked at Banga's USENIX paper and they have a nice discussion of this issue. setup sigio and such on new fd (dorky, we have to do this in linux rather than inheriting it from the listening fd. but it has yet to show up on the profile radar, so, whatever :)) Hah. It showed up on my profiling; the kernel I'm running has routines so the child fd inherits certain settings from the parent. read() in the header (usually done in one read, but rarely will block and require falling back to a POLL_IN on the new fd) Well, we _NEVER_ want to block. Ever. And in my particular case, it is quite common for the header/data to be spread out over several reads. of course, this could change if you had a situation where you could burn through events like nothing else and simply couldn't deal with the lock-step.. Correct. I need this for a web caching proxy. The above loop won't work in my particular case. Also, I would guess that you would start getting into locking problems, and how to cancel a signal which has already been posted. locking problems? For asynchronous signal delivery, you alluded to this problem earlier as well. Since you're blocking signals, this isn't a problem. yes, the possibility of getting stale events in the queue is _annoying_. This is going to be a problem in any system that passes state deltas to the process in a queued manner. hacks could be put in, and perhaps should, to remove events in the queue for a fd when it is closed, etc. take the web server case again. it is quite possible to close() an fd while there is an event queued for it, and then accept() a new fd that now has a bogus event coming down the pipe for it. I get around this garbage in the cheesy web server by doing deferred close()s on fds based on the length of the queue when I stopped being interested in the fd (and as such turned off sigio delivery). Its gross. Exactly. Sometimes, we just want to close() an fd, even if there are pending events, and then immediately re-open with a new fd. Deferred closes are not an option. What I do at the moment is remove queued events/state when the fd is closed. (actually, my implementation sucks a bit, as I re-scan the state for this
Re: Pictures from USENIX
It seems David Greenman wrote: A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Nothing. I just remember someone pointing out in a previous e-mail that all the core members had some sort of beard. Very few core members have beards, so whoever said that was wrong. Nah, are you sure ?? I havn't shaved in over a decade :) Yes, I'm sure that all of the core members don't have beards (proven with just myself not having one). Although now that I think about it, about 25% of us do. This thread doesn't belong on hackers. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
It seems David Greenman wrote: A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Nothing. I just remember someone pointing out in a previous e-mail that all the core members had some sort of beard. Very few core members have beards, so whoever said that was wrong. Nah, are you sure ?? I havn't shaved in over a decade :) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: Connect and so on..
On Mon, 28 Jun 1999, Ladavac Marino wrote: Essentially, we're trying to mediate system calls. Read, Write, Open, Socket calls from userland are caught, information about the calling process (i.e. caller UID) are sent to an external source for authorization and depending on the reply, the system call will proceed or not. This is the reason why the connection should be atomic and (so I think) in the kernel. Can't have other calls going through in the interim. [ML] If I understand this correctly, only the syscall which is being authenticated must block during the authentication. This makes the authentication atomic from the viewpoint of the syscall. The other processes/kernel supported threads may proceed. Sounds like RAGF(spelling?) scheme you're doing there. Sorry about tardy response, I've been away. What you describe above is correctly expresses what I was trying to say. Could you point me to more about this (RAGF) scheme? NFS daemon approach may be feasible for you, because this is exactly what it does. You have one central authentication daemon which is blocked in kernel syscall all the time, unless some other process (syscall) requests the authentication. The daemon then returns to user space, performs the neccessary authentication, and goes back into kernel with results. This is the way I would implement it, because it makes adding authentication schemes rather simple. [ML] /Marino Excellent, thank you. Although, looking through NFS code doesn't sound like fun. Oh well, time to pay my dues. Something else I need to look into is how to effeciently pass info back and forth from kernel space to user space and vice-versa. (See above for brief background of what I'm attempting to do). For every syscall being tracked/authenticated, a record is constructed and needs to be sent to the (userland) comms daemon that will send it to another server and await a response. In the mean time, the process making the syscall is blocked. Understandably this will really cut off process performance at the knees, but then again this a proof of concept project. One can easily imagine the processes being blocked starting to backup, since the comm daemon is competing for processor time, even if every entry into the kernel by (arbitrary) tracked syscalls resets the priority of the comms daemon to a higher level. (I'm trying to let the daemon get as much of the processor as possible to complete what it is doing. It releases it's quanta whenever it needs to wait for something). The comms daemon would keep a table of records received from the kernel to be authenticated, and only mark it as read when it has received a response (while being preempted many times), so that at the next arbitrary tracked syscall, the kernel would look at this table, look at all the status word fields (one per record) and read in the (response) records, if any, and mark these slots as unused for later use. This table would have to be in userland, with a single byte status field for every record. The table would have fixed size records, say 1k per entry. The seond field holds the PID and the third is free form. The status field would act as a signal to the kernel that a response was received. The kernel would read the status and PID and unblock the process, and either let the syscall proceed or not. Can't use a restart here, because, as I understand it, this would create another syscall, and hence a loop. Now, what I need to know is what is the best way to move this info over the fence, back and forth. Seems copyin() and copyout() are used throughout kernel code. With a table with fixed size records, I would simply need to loop through every status byte with copy*(addr + size(record)) to find out the responses, without (*ahem*) being interrupted. Is there an easier/better/more effecient subsystem to use that I don't know about? There are a lot of timing issues here, and I'm sure I've missed some. The comms daemon becomes a huge bottleneck for the processes that happen to make syscalls that are being tracked, but I don't see a better way. One of the things that the comm daemon would do is cache a lot of these recurring requests so that it wouldn't have to go "outside" to respond to the auth request. Also, if someone can point me to some books/papers/soliloquies of how to effeciently manage a shared table, I'd be grateful. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Repalcement for grep(1)
On Mon, 5 Jul 1999, Archie Cobbs wrote: Are you sure you're stripping out the newline and carriage return? You know, that did it. I'l put together another version tonight incorporating all the bug fixes and suggestions I have received over the past few days. More on that shortly. Jamie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Mon, Jul 5, 1999, Joe Abley wrote: On Mon, Jul 05, 1999 at 05:11:57AM -0500, Chris Costello wrote: I've been encountering people recently who, for one reason or another, are unable to find information for themselves when they have a question on FreeBSD. I propose an rtfm(1) command, and I've got some Perl code that works. If people are interested, I will continue with it, and write a man page. The source is attached. It would be good if you could use fetch(1) instead of forming the HTTP request yourself. That way people who already have fetch working through proxies don't have to modify anything to use rtfm. Is there a particular reason you're writing it in perl? Mostly regexp and such. If I can figure out how to use the regexp code for C, I'd probably rewrite it. Joe -- Chris Costello[EMAIL PROTECTED] The generation of random numbers is too important to be left to chance. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
Due to the number of fixes I have received over the past few days, I
decided to put together a new release of grep. It was either this or
watch _Titanic_ on Cinemax.
I incorporated a huge patch from Dag-Erling Smorgrav which as he put it
"cleaned it up to make it conform to FreeBSD's coding style standards. I
also removed a bunch of unused or unnecessary variables, fixed one or two
minor bugs, and made a few entirely subjective cosmetic improvements." He
also modified the Makefile to generate links for fgrep and egrep as well.
All things I was going to worry with when it was done. :) I added the
links for zgrep. I changed the sample length in the binary checker from
64 bytes to 32 at his suggestion. This is the same as how GNU grep
handles it.
I changed it so that even when called as grep or with -G, it treats the
pattern as an extended regular expression. GNU grep behaves the same way.
Simon Burge sent code to enable -w as well as several smaller code fixes
and clean ups.
I changed bin_file() and seekable() to operate on a pointer to a FILE
rather than on an integer file descriptor.
Due to popular demand, I added support for searching gzip compressed
files. GNU grep only supports searching gzip compressed files. It did
not bloat my code as much as I expected; I vapor locked and forgot about
libz, which did all the hard work for me. It would be trivial to add
support for bzip and bzip2 files for those OSes that have libbz2.
Archie Cobbs dropped the hint needed to solve the problems with -x. Right
now, I wrap the pattern with "^(" and ")$". I know GNU grep does this,
but is this correct?
Now, as it stands, I beleive this implementation is identical to GNU grep,
except for the added -o option, and the -A num, -B num, -C, and -num
family of options. Despite what I said before, I will implement them.
Another popular demand thing. So I will take care of that over the next
few days.
It would be really swank if someone were to go over what I have and make
sure it is correct. I know I was blowing $ before, and I think that is
correct now.
Due to problems with the previous download site (it is down as I type
this), I will place this file in two locations:
ftp://dragon.ham.muohio.edu/pub/howardjp/grep-0.3.tar.gz
ftp://ftp.wam.umd.edu/pub/howardjp/grep-0.3.tar.gz
It will probably be slow to hit the second, as it may be down until
tomorrow morning.
Thank you everyone who helped,
Jamie
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: 'rtfm' script
On Mon, 5 Jul 1999, Alex Zepeda wrote: P.S. If you're looking for an easy to use regexp implementation, and aren't afraid of C++, check out Qt; if you're looking for more of a challenge, there's always the need for an rtsl(1) ;) rtsl(1) = glimpse(1) : - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
Frivolous is to have a page with pics from Ulf's Partys and play "Spot The Devloper." Stefan On Sun, 4 Jul 1999, Jordan K. Hubbard wrote: I'm going to have a "core team page" worked on which has pictures and brief bios, perhaps something by next week. Such things may seem frivolous, but I it helps people relate a little more directly to the core team if they can see what they look like and read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) - Jordan On Sun, 4 Jul 1999, Wilko Bulte wrote: Which makes a good case for a permanent picture gallery @ www.freebsd.org I guess. I can donate a bunch of pictures taken at last year's hackersparty here in the Netherlands. When FreeBSDcon comes closer, I'll probably be be asking which of the developers are coming to it. I'm going to try to get some large group photos etc etc. - bill fumerola - [EMAIL PROTECTED] - BF1560 - computer horizons corp - - ph:(800) 252-2421 - [EMAIL PROTECTED] - [EMAIL PROTECTED] - To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: mmap question
: Which is fine and dandy, I'll just stat() the file to get the filesize and :mmap() it. But what happens in someone comes along and replaces the file :with :a larger file? I understand that my view of the file will change to the new :file, but only the length that I mmap()ed originally. Do I have to :periodically stat() the file to determine if I need to re-mmap() it should :the file size change? And if so, doesn't that partly diminish the usefulness :of mmap()? I mean, sure you can edit the file as a file and they are :reflected in the in-memory image, but how many edits don't change the file :size? You can mmap() an area that is larger then the file. For example, you could mmap a 100 bytes file into a 32MB area. If the file then grows, you can access the new data up to the amount of space you reserved. However, accessing pages beyond the file EOF via the mmap() will result in a segfault. This is also true if a file is truncated out from under you - previously valid data pages will disappear. If you mmap() the exact size of a file and the file grows, you have to mmap() the new area of the file or unmap the old area and remap the entire file to gain access to the additional data. You can mmap() areas of a file in a piecemeal fashion though this should not be taken to extremes since it will slow down page-fault handling. Most programs using mmap() use it on files which are not expected to change out from under the program's control. Thus most programs using mmap() simply map the file's full size and do not try to do anything fancy. : Kelly : ~[EMAIL PROTECTED]~ -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IPv6 and FreeBSD
Found this on slashdot. http://www.infoworld.com/articles/hn/xml/990705hn3com.xml There is a link to www.ipv6.org which lists IPv6 implementations. FreeBSD is listed as well as Linux, OpenBSD, and NetBSD. Linux ships with IPv6, OpenBSD will ship it's next version with IPv6. Any idea what the current status of our IPv6 implementation ? Josef -- Josef Grosch | Another day closer to a |FreeBSD 3.2 [EMAIL PROTECTED] | Micro$oft free world | UNIX for the masses To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Replacement for grep(1) (part 2)
On Mon, 05 Jul 1999 21:14:36 -0400, Jamie Howard wrote: It would be really swank if someone were to go over what I have and make sure it is correct. I know I was blowing $ before, and I think that is correct now. Hi Jamie, One way to make it easier for people to test drive your software under FreeBSD is to create a port for the software (FreeBSD-style port, not NetBSD-style port). I'm home with flu right now, but if nobody else has done a port for your grep(1) by Thursday morning, I'll do it for you then. Would you be happy being listed as the maintainer of such a port? The reason I'm suggesting using a port rather than having the code imported into the base system is that it allows people to "opt in" to testing it, rather than forcing it down people's throats. The idea is that, when it's proved itself as a port, enough people will clamor for its inclusion in the base system for that to become a reality. Trying to get software imported directly into the base system without a trial run as a port is almost always a painful exercise (and I'm not talking about technical issues here). Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
Soren Schmidt wrote: It seems Wes Peters wrote: Tim Vanderhoek wrote: On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? Here's what I have so far: 55.4, 11.3, "phk, sos" # Denmark That should be: 55.4, 11.3, "phk" # Denmark 57.2, 10.2, "sos" # Denmark OK, I've put the latest version in ~wes/FreeBSDmarkers on freefall, and it is public writable. Have at it. I'll check in a few days and when the edits have tapered off, I'll commit it back in CVS. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC http://softweyr.com/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Pictures from USENIX
David McNett wrote: On 04-Jul-1999, Jordan K. Hubbard wrote: Such things may seem frivolous, but I it helps people relate a little more directly to the core team if they can see what they look like and read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) Far from frivolous, I think that things like this will go a long way to dispel the common misconception that FreeBSD is developed by a small, closed, and unapproachable cadre of monks. Shouldn't be too unwieldy, assuming you don't also choose to include the cats of the core team as well. Why not? Cats are important, you know. -- 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: Pictures from USENIX
Tim Vanderhoek wrote: On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? Here's what I have so far: # # Walnut Creek, our good friends. # 37.91 -122.06 Walnut Creek # Walnut Creek CD-ROM # # FreeBSD core team members # 37.9, -122.3, asami # Berkeley, CA 40.0, -123.5, jkh # Miranda, CA 40.1, -105.3, gibbs, wosh # Boulder, CO (wow!) 45.5, -122.6, davidg# near Portland, OR 47.5, -122.4, jdp # Seattle, WA 42.4, -71.1, wollman # Boston, MA 39.2, -77.0, jmb # Silver Spring, MD 56.0, -4.5, gary # Glasgow, UK 55.8, 37.6, ache # Moscow 53.0,5.0, guido # Eindhoven, the Netherlands 55.4, 11.3, phk, sos # Denmark 52.0, 13.8, joerg # Germany 29.7, -95.4, rich # Houston, TX 39.8, -86.2, dyson # Indianapolis, IN -33.55,151.1, bde # Sydney, Australia. -31.58,115.49, peter # Perth, Australia. # # Other committers # 40.55 -111.90 wes # South Jordan, UT 46.59 -112.04 nate # Helena, MT 43.19 -89.38 jlemon # Madison, WI 34.13 -118.12 mph # Pasadena, CA -34 18markm# Cape Town, South Africa 42.02 -93.67 ghelmer # Ames, IA 29.99 -90.13 nectar # Metairie, LA 42.34 -71.19 gwollman # Brighton, MA -34.53 138.35 newton, kris, grog # Adelaide, SA Australia 43.37 -79.79 hoek # Burlington, ON Canada 44.05 -123.08 jmg # Eugene, OR 59.7210.85 eivind # Ski, Norway 53.33 9.59 stb # Hamburg Germany 38.54 -121.76 obrien, mharo# Davis, CA 43.7110.40 luigi# Pisa, Italy 51.67 0.61 brian# Amersham, Bucks, UK 48.8 2.28 ollivier # Les Ulis, France 55.87-4.26 , roger # Glasgow, UK 40.1-105.3, merry, passe # Boulder, CO (wow!) # # Others? # 50.70 6.2 gellekum # Thomas Gellekum, Aachen, Germany 12.5877.35 koshy# Joseph Koshy, Bangalore, India 48.36 2.99 philippe # Phillipe Charnier, Cannes Ecluse, Fran ce The three marked Others were individuals who responded to didn't appear to have accounts on freefall. This looks pretty cool when used with xearth -markerfile, you can see that the sun never sets on the FreeBSD empire. ;^) So far, Eivind is the northernmost and Grog and the Adelaide crowd the southernmost. BDE is the easternmost and Jordan the westernmost. The largest concentration so far is Boulder Colorado with 4, followed by the Adelaide gang with 3. This, of course, doesn't count the bay area which is a lot of small town. -- 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: Pictures from USENIX
David Scheidt wrote: On Mon, 5 Jul 1999, Greg Lehey wrote: On Sunday, 4 July 1999 at 15:36:21 -0400, Bill Fumerola wrote: It also clears up the misconception that being a member of -core requires a beard. A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Greg Depends if it 100 F or not. David, clean shaven for the first time in months, Scheidt It's 100F here on a regular basis through the summer. I've had a beard for over 10 years now. I shaved it once right after I was married. My wife told me I looked like my brother and should grow it back posthaste. ;^) -- 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
FreeBSD locations (was: Pictures from USENIX)
On Monday, 5 July 1999 at 0:12:55 -0600, Wes Peters wrote: Tim Vanderhoek wrote: On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? Here's what I have so far: 52.0, 13.8, joerg # Germany You've put Jörg somewhere near Berlin. He's in Dresden, further to the South-East. -31.58,115.49, peter # Perth, Australia. Peter's gone to the USA, we think. -34.53 138.35 newton, kris, grog # Adelaide, SA Australia I'm not in Adelaide, remember? Here are my coordinates: -35.14 138.77 grog So far, Eivind is the northernmost and Grog and the Adelaide crowd the southernmost. John Birrell's further South (Melbourne, for a first approximation): -37.7144.9 jb BDE is the easternmost and Jordan the westernmost. The largest concentration so far is Boulder Colorado with 4, followed by the Adelaide gang with 3. Hmm. Doesn't Daniel O'Connor have commit privileges? And it's time for Mike Smith to come home, then we'd have 5 :-) Greg -- See complete headers for address, home page and phone numbers finger g...@lemis.com for PGP public key To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD locations (was: Pictures from USENIX)
Greg Lehey wrote: John Birrell's further South (Melbourne, for a first approximation): -37.7144.9jb Close enough. Danny O'Callaghan (danny) and Peter Hawkins (thpish) are in Melbourne too. -- John Birrell - j...@cimlogic.com.au; j...@freebsd.org http://www.cimlogic.com.au/ CIMlogic Pty Ltd, GPO Box 117A, Melbourne Vic 3001, Australia +61 418 353 137 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
For your information http://www.mapblast.com specifies LongLat at the bottom of the page when you are looking at a map. Just move the icon to the right place. Cheers Nick n_hibma[ Icon Latitude: 45.869154, Longitude: 8.620118 ] On Mon, 5 Jul 1999, Wes Peters wrote: Tim Vanderhoek wrote: On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? Here's what I have so far: # # Walnut Creek, our good friends. # 37.91 -122.06 Walnut Creek # Walnut Creek CD-ROM # # FreeBSD core team members # 37.9, -122.3, asami # Berkeley, CA ... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
It seems Wes Peters wrote: Tim Vanderhoek wrote: On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? Here's what I have so far: 55.4, 11.3, phk, sos # Denmark That should be: 55.4, 11.3, phk # Denmark 57.2, 10.2, sos # Denmark We dont live THAT close together :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? Here's what I have so far: 55.4, 11.3, phk, sos # Denmark That should be: 55.4, 11.3, phk # Denmark 57.2, 10.2, sos # Denmark We dont live THAT close together :) Or rather, they live on opposite ends of the country ... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
In message pine.hpp.3.96.990704153517.11529a-100...@hp9000.chc-chimes.com Bill Fumerola writes: : It also clears up the misconception that being a member of -core requires : a beard. If it did, then Jordan would be out. :-) Justin too. Those are the only two core members that I can even recall what they looked like... I don't think I've ever seen a 5 O'clock shadow on Justin... Certainly not on a regular basis. Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
In message 37804ce7.d821b...@softweyr.com Wes Peters writes: : 40.1, -105.3, gibbs, wosh # Boulder, CO (wow!) wosh? Didn't know there was a wosh in core. It certainly isn't me, since I'm in Boulder, but not in core. There appears to be no wosh account on freefall. : 40.1-105.3, merry, passe # Boulder, CO (wow!) Warner Losh, Ken Merry, Steve Passe and (until recently) Sean Kelly. Boulder is a small town, since I used to work with Ken, Sean and Justin. I now work with Steve Passe : largest concentration so far is Boulder Colorado with 4, followed by Yes. And if those are the only committers, their places of employment are separated by only a few blocks (literally walking distance, I've made the walk before when I was at Pluto since my wife works across the street from Timing Solutions) Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Repalcement for grep(1)
Hello! On Sat, Jul 03, 1999 at 05:00:41PM -0400, Todd Vierling wrote: [...] Hm. Adding ^ and $ should work, provided you don't specify either REG_NOTBOL or REG_NOTEOL. (I assume that (foo) above, including the parens, is the RE. With the parens, it depends whether you're using standard REs or extended REs. :) But be careful about adding ^ and $ to something like (extended syntax) foo|bar. ^foo|bar$ is wrong, and ^(foo|bar)$ works HERE but not always, as when the original regex uses \number backreferences, you must patch them (increase by one), and you're hosed if \9 is already used. [...] Regards, Hannah. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
In message pine.gso.3.95q.990705091442.676n-100...@elect8 Nick Hibma writes: : For your information : http://www.mapblast.com : specifies LongLat at the bottom of the page when you are looking at a : map. Just move the icon to the right place. That puts my current employer at 40.029322, -105.227900 and Pluto at 40.023712, -105.225382. Well, I'd have to knock a couple of significant figures off those since the addresses for these two places don't quite match the icon on the map... I told you they were walking distance... :-) Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
'rtfm' script
I've been encountering people recently who, for one reason or
another, are unable to find information for themselves when they
have a question on FreeBSD.
I propose an rtfm(1) command, and I've got some Perl code that
works. If people are interested, I will continue with it, and
write a man page.
The source is attached.
Sample output:
(-s = simple, don't search sections 3, 4, or 9, and 'e' means
'exact', or 'use whatis instead of apropos')
-
$ rtfm -s -e ASCII
Manual pages found:
ascii(7)
hexdump(1)
map3270(5)
mset(1)
neqn(1)
od(1)
pfbtops(1)
Found FAQ entries:
1.18. Where can I get ASCII/PostScript versions of the FAQ?
http://www.freebsd.org/FAQ/FAQ19.html#19
1.19. Where can I get ASCII/PostScript versions of the Handbook?
http://www.freebsd.org/FAQ/FAQ20.html#20
1.20. The ASCII handbook isn't plain text!
http://www.freebsd.org/FAQ/FAQ21.html#21
--
Chris Costelloch...@calldei.com
I'll rob that rich person and give it to some poor deserving slob.
That will *prove* I'm Robin Hood.
-- Daffy Duck, Robin Hood Daffy, [1958, Chuck Jones]
#!/usr/bin/perl -w
# Copyright (c) 1999 Chris Costello
# All rights reserved.
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions
# are met:
# 1. Redistributions of source code must retain the above copyright
#notice, this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
#notice, this list of conditions and the following disclaimer in the
#documentation and/or other materials provided with the distribution.
#
# THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
# ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
# OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
# HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
# LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
# OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
# SUCH DAMAGE.
use IO::Socket;
my ($mancnt, $line, @manuals, $manual, $simple, $exactword, @faqs);
my ($http_socket);
$mancnt = 0;
$simple = 0;
$exactword = 0;
# Somehow I need to be able to try and find a 'closest mirror'.
$http_server = 'www.freebsd.org';
$faq_path = '/FAQ';
usage if $#ARGV 0;
while ($_ = $ARGV[0], /^-/) {
shift(@ARGV);
if (/^-s/) { $simple++; } # see simple description in man page
elsif (/^-e/) { $exactword++; }
elsif (/^-h/) { usage }
}
$ent = $ARGV[0];
$prog = whatis if $exactword;
$prog = apropos unless defined($prog);
# First check to see if we have a man page.
open(APROPOS, $prog $ent|) || die error encountered running $prog: $!;
while (defined($line = APROPOS)) {
chomp($line);
$mancnt++;
if ($line =~ /$ent: nothing appropriate/) { last; }
# innovation.
$line =~ s/^(.+?)\(([0-9nqt]+?)\).*/$2 $1/g;
push(@manuals, $line);
}
close(APROPOS);
if ($mancnt 0) {
print Manual pages found:\n;
foreach $manual (@manuals) {
my ($sect, $mman) = split(/ /, $manual);
if ($simple 0 ($sect =~ /[349qt]+/)) {
next;
}
print$mman($sect)\n;
}
}
$http_socket = IO::Socket::INET-new($http_server . ':80');
print $http_socket GET $faq_path/ HTTP/1.0\r\n\r\n;
while (defined($line = $http_socket)) {
chomp($line);
# superiority.
if ($line =~ /^DD(.+?)A HREF=\(.+?)\(.+?).*$/) {
my ($faq_ent, $faq_page, $faq_question);
$faq_ent = $1;
$faq_page = $2;
$faq_question = $3;
if ($faq_question =~ /$ent/) {
push(@faqs, sprintf(%s|%s|%s, $faq_ent, $faq_page,
$faq_question));
}
}
}
close($http_socket);
print \nFound FAQ entries:\n;
foreach (@faqs) {
my ($faq_ent, $faq_page, $faq_question) = split(/\|/);
print$faq_ent $faq_question\n
http://$http_server/FAQ/$faq_page\n;;
}
# usage:
# prints usage info and exits.
sub usage {
print STDERR usage: rtfm command\n;
exit 1;
}
Re: Porting LILO to FreeBSD
Warner Losh wrote: In message pine.bsf.4.05.9907021107080.24927-100...@thneed.ubergeeks.com Adrian Filipi-Martin writes: : The standard boot partition selection softwre also works fine : booting windoze OS's from other disks. All you need to do is set the disk : id in the DOS MBR to the correct number, 0x81 for your second disk. That's : the only thing that MS doesn't do correctly whe installing the OS on the : non-primary disk. I used to do this a long time ago to boot FreeBSD of the : C drive and the other stuff off of second C drive. How does one do that? What tools do you use? I did this, using an old copy of Norton Disk Edit. It didn't work, although it did do something. Before I did it, if I told os-bs beta to boot DOS, it would give a `non-system disk or disk error' message (if I recall correctly; if not, it simply hung with no message). After changing the disk ID, it got as far as `Starting MS-DOS' but hung at that point. Note that os-bs beta was not good enough on its own. Actually, come to think of it, I didn't quite do this - I changed the disk ID in the boot sector of the DOS partition, rather than the MBR. Given that you do this with Norton Disk Editor, do you have to run DE and tweak it every time you want to change the disk? I guess one could write progs that runs under either O/S that will just toggle the appropriate byte, making it a bit less convenient. It's still a bit of a drag if you want to boot one O/S and the other is enabled, and you're powering up - you have to boot the wrong one, toggle the byte, and then reboot. I subsequently gave up and tried to uninstall os-bs beta. It told me that the uninstall option was not available. So I used Norton Disk Editor to restore my LILO boot record - except I mistakenly specified a logical rather than a physical sector. I spent the next day recovering from this (to the point where I had the screwdrivers out!). I gave myself a hundred lines: I will not confuse the physical and the logical; I will not confuse the physical and the logical... In the end I was back to square one. But then I remembered the real reason I had such a screwy setup - not for DOS itself, but because I wanted Windoze 3.1. But I haven't actually needed it in about two years, so I installed os-bs 3.5, scrapped the \Linux directory on my C: drive, and I'm quite happy (I can still boot DOS 6.2 from Win 95 by pressing F8 and selecting `Boot previous version of MS-DOS'). I still think it would be a good thing to port LILO to FreeBSD (and/or DOS/Windoze for that matter), but I'll leave that for another time (or another person!) -- Dr Graham Wheeler E-mail: g...@cequrux.com Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security Specialists WWW: http://www.cequrux.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Porting LILO to FreeBSD
Warner Losh wrote: In message 199907031912.maa01...@dingo.cdrom.com Mike Smith writes: : Neither; he'll have to tell the BIOS that the drive's not there. That's what he's doing right now... He doesn't want to keep doing this since it is such a PITA. However, other posters in the thread gave me enough hints that I think that I can help him make it work. LILO's trick of installing a small translating shim on INT 13 may be just the ticket... But how will he install LILO, if he only has Windoze and FreeBSD? He could install Linux on his Windoze drive, get LILO bootstrapped, and take it off again afterwards, but making any changes to the LILO config will be tricky (I suppose he could make a bootable LINUX floppy). If he wants to install the shim, it has to be resident on the drive somewhere, but that's easy to sort out. It may be better to leave the shim (any_d.b) on the FreeBSD partition - LILO relies on it being at a known physical location on the disk. Under Windoze, if he ran disk defragmenter, he could break the boot. Now that I think of it, I'm probably lucky that I have never defragmented my Windoze drive or I would most likely have broken my LILO. -- Dr Graham Wheeler E-mail: g...@cequrux.com Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security Specialists WWW: http://www.cequrux.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Porting LILO to FreeBSD
Robert Nordier wrote: A Microsoft-style MBR gets the drive number from the byte at offset 0 of the partition entry (field dp_flag of structure dos_partition in /sys/sys/disklabel.h). This is usually known as the active flag, and all standard fdisk utilities set this to 0x80 (corresponding to BIOS fixed drive 0) when flagging a partition as active. This can be patched by hand to some other value (eg. 0x81 for BIOS fixed drive 1) but in a standard pre-Win95 OSR2 MBR this causes problems, as the MBR code validates the partition table entries, and will respond to the 0x81 with the message Invalid partition table followed by a hang. Man, I wish I read this earlier on the weekend. One of the things I tried doing was haxing the FreeBSD fdisk program so that I could pass a different value for the flag as a command line argument. After doing this, I got just that behaviour. Unfortunately, so many other things had been tweaked by this stage (I had already clobbered the DOS boot sector once and had managed to reconstruct it by hand with a bit of trial and error) that I ended up doing more damage in my attempt to get the machine to boot again... The easiest approach, probably adopted by LILO, is to install a wrapper around the BIOS int 0x13 services and just change drive numbers as they go by. That's exactly what LILO does, I believe. -- Dr Graham Wheeler E-mail: g...@cequrux.com Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security Specialists WWW: http://www.cequrux.com/ To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Login.conf (Whose problem is this) ?
On Sat, 03 Jul 1999 18:57:06 MST, John Polstra wrote: This stuff is old and obsolete. LOGIN_CAP_AUTH isn't supported any more. (It never was fully supported, actually.) Don't use it. There's an open PR for this, PR 10115. I assume all that's required is that we smack the outdated comments from login.conf? Ciao, Sheldon. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Dynamic linking
Hi everyone! Is there a way of making dlopen return an error from the shared object's _init function? Thanks. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() scalability
Also, you really want to return more than one event at at time in order to amortize the cost of the system call over several events, this doesn't seem possible with callbacks (or upcalls). yes, that would be a nice behaviour, but I haven't seen it become a real issue yet. the sigwaitinfo() syscall is just so much lighter than all the other things going on in the situation where you actually use this system. How about a modified sigwaitinfo that will return a number of waiting siginfo -- of course this introduces the problem of deciding how long to wait for new additions to the queue before returning. This is something similar to the Nagle algorithm.. Or perhaps sigwaitinfo could buffer siginfo's in user space, although this introduces complexity if you want the ability to cancel queued signals... Regards, Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD locations (was: Pictures from USENIX)
Greg Lehey wrote: On Monday, 5 July 1999 at 0:12:55 -0600, Wes Peters wrote: [..] -31.58,115.49, peter # Perth, Australia. Peter's gone to the USA, we think. Not yet. Not till later this year. Cheers, -Peter To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
On Mon, Jul 05, 1999 at 12:12:55AM -0600, Wes Peters wrote: [cc's trimmed] Tim Vanderhoek wrote: On Sun, Jul 04, 1999 at 12:15:02PM -0700, Jordan K. Hubbard wrote: read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) Did Wes Peters finish his collection of committer ICBMNet lat/long co-ordinates? Here's what I have so far: # # Walnut Creek, our good friends. # 37.91 -122.06 Walnut Creek # Walnut Creek CD-ROM # snip 49.01, -122.68, cpiazza # near Vancouver, BC Wow, right on the 49th parallel! (FYI I can walk to the US border from my apartment...) snip So far, Eivind is the northernmost and Grog and the Adelaide crowd the southernmost. BDE is the easternmost and Jordan the westernmost. The largest concentration so far is Boulder Colorado with 4, followed by the Adelaide gang with 3. This, of course, doesn't count the bay area which is a lot of small town. Not enough Canadians, I think. -Chris -- cpia...@home.net cpia...@freebsd.org Optimist, n. A proponent of the doctrine that black is white.-Ambrose Bierce To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Dynamic linking
- jir ji jimaria j...@logx.com irc#tokyo15 icq jir 3941247- http://www.enjoynight.com/cgi-bin/friends/ji/familychat.cgi vai...@pcg-c1@e arcQQW Hi everyone! Is there a way of making dlopen return an error from the shared object's _init function? Thanks. What matters? May you instool some windows'soft? and change *.dll file serch *.dll and *is err's *dll You got? To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() scalability
How about a modified sigwaitinfo that will return a number of waiting siginfo -- of course this introduces the problem of deciding how long to wait for new additions to the queue before returning. This is you'd just have a 'give me up to X' parameter, if you get a single one under high load they will queue up until you call it next time.. waiting around stinks, these operations usually want low latency. could buffer siginfo's in user space, although this introduces complexity if you want the ability to cancel queued signals... yes, that is the hard part :) -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Porting LILO to FreeBSD
On Mon, 5 Jul 1999, Graham Wheeler wrote: Date: Mon, 05 Jul 1999 14:23:36 +0200 From: Graham Wheeler g...@cequrux.com To: Warner Losh i...@harmony.village.org Cc: hack...@freebsd.org Subject: Re: Porting LILO to FreeBSD Warner Losh wrote: In message 199907031912.maa01...@dingo.cdrom.com Mike Smith writes: : Neither; he'll have to tell the BIOS that the drive's not there. That's what he's doing right now... He doesn't want to keep doing this since it is such a PITA. However, other posters in the thread gave me enough hints that I think that I can help him make it work. LILO's trick of installing a small translating shim on INT 13 may be just the ticket... But how will he install LILO, if he only has Windoze and FreeBSD? He could install Linux on his Windoze drive, get LILO bootstrapped, and take it off again afterwards, but making any changes to the LILO config will be tricky (I suppose he could make a bootable LINUX floppy). If he wants to install the shim, it has to be resident on the drive somewhere, but that's easy to sort out. It may be better to leave the shim (any_d.b) on the FreeBSD partition - LILO relies on it being at a known physical location on the disk. Under Windoze, if he ran disk defragmenter, he could break the boot. Now that I think of it, I'm probably lucky that I have never defragmented my Windoze drive or I would most likely have broken my LILO. I have, it works fine. I believe that the defrag program is smart enough not to move those precious bytes from the beginning of the partition. Come to think of it, if it did the system might not boot even if one wasn't using LILO. -- Dr Graham Wheeler E-mail: g...@cequrux.com Cequrux Technologies Phone: +27(21)423-6065/6/7 Firewalls/Virtual Private Networks Fax:+27(21)24-3656 Data/Network Security Specialists WWW: http://www.cequrux.com/ 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: Login.conf (Whose problem is this) ?
Sheldon Hearn wrote: This stuff is old and obsolete. LOGIN_CAP_AUTH isn't supported any more. (It never was fully supported, actually.) Don't use it. There's an open PR for this, PR 10115. I assume all that's required is that we smack the outdated comments from login.conf? Yes, I think so. 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: Porting LILO to FreeBSD
In message 3780a3c8.db048...@cdsec.com Graham Wheeler writes: : But how will he install LILO, if he only has Windoze and FreeBSD? Actually, he's happily booting Win95 and OpenBSD now. He's using radish which makes things just work. It did take some work getting rid of vestages of a WinNT install on the Win95 disk (it used to dual boot), but once that was done things were happy. No need to get Lilo involved at all :-). Warner To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Dynamic linking
hi, there! On Mon, 5 Jul 1999, Andrew Iltchenko wrote: Is there a way of making dlopen return an error from the shared object's _init function? Thanks. You can do this by yourself by defining something like int _module_init() and calling it after dlopen'inig the object /fjoe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
On Mon, 5 Jul 1999, Greg Lehey wrote: It also clears up the misconception that being a member of -core requires a beard. A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Nothing. I just remember someone pointing out in a previous e-mail that all the core members had some sort of beard. - 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: Repalcement for grep(1)
Jamie Howard writes: Perhaps this will help with -w? Yes, I received a patch from Simon Burge which implements this. It also beats using [^A-Za-z] and [A-Za-z$] as I was and GNU grep does. I am still having trouble with -x though. It turns out that even if I specify a commandline with a pattern of the form ^pattern$, it fails. If I specify ^pattern it works. If I specify pattern$ it does not. I have yet to find a case where my version will sucessfully match when a $ is at the end. Has anyone encountered anything like this before? Are you sure you're stripping out the newline and carriage return? -Archie ___ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD locations (was: Pictures from USENIX)
Greg Lehey wrote: On Monday, 5 July 1999 at 0:12:55 -0600, Wes Peters wrote: Here's what I have so far: 52.0, 13.8, joerg # Germany You've put Jörg somewhere near Berlin. He's in Dresden, further to the South-East. That's what he mailed me. I can't find a map of Dresden with lat- long right now. Help? -31.58,115.49, peter # Perth, Australia. Peter's gone to the USA, we think. Not another one? The FreeBSD Aussie invasion continues... -34.53 138.35 newton, kris, grog # Adelaide, SA Australia I'm not in Adelaide, remember? Here are my coordinates: -35.14 138.77 grog You didn't respond, so I lumped you in with the Adelaid crowd. I knew you were south of Adelaide, but I couldn't find Echunga on the only map I could find that gave coordinates. So far, Eivind is the northernmost and Grog and the Adelaide crowd the southernmost. John Birrell's further South (Melbourne, for a first approximation): -37.7144.9 jb BDE is the easternmost and Jordan the westernmost. The largest concentration so far is Boulder Colorado with 4, followed by the Adelaide gang with 3. Hmm. Doesn't Daniel O'Connor have commit privileges? And it's time for Mike Smith to come home, then we'd have 5 :-) Oh lord, are we going to have to rename ourselves OzBSD now? ;^) Daniel doesn't have an account on freefall. -- 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
mouse/keyboard usage statistics...
Hi, just as a curiosity (or maybe not...) i was wondering what would be the easiest way to get rough estimate of the number of keypress and mouse movements i do. It appears that vmstat -i already gives some estimate for the keyboard, e.g. ordinary keys give a couple of interrupts (on press/release), but whenever the autorepeat starts I get some 18 int/s and thus the data is extremely noisy. Is there a way to get 'true' keypress counts in the sc driver, and especially log this info into syslog when the system is shut down ? Same problems for mouse movements, except perhaps that i can hook into moused and so the problem is a little bit easier to deal with. cheers luigi ---+- Luigi RIZZO, lu...@iet.unipi.it . Dip. di Ing. dell'Informazione http://www.iet.unipi.it/~luigi/ . Universita` di Pisa TEL/FAX: +39-050-568.533/522 . via Diotisalvi 2, 56126 PISA (Italy) http://www.iet.unipi.it/~luigi/ngc99/ First International Workshop on Networked Group Communication ---+- To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm script'
On Mon, Jul 5, 1999, Bill Fumerola wrote: I'm in favor of the rtfm script. It's amazing the positive things that come out of an offhand IRC comment. [ from http://www.emsphone.com/FreeBSD/log.cgi/19990704.txt ] [15:33] cmc First it'll search the man pages. Then the handbook. Then the FAQ. Then, maybe see if I can find out if they start bitching, and if so, email Jesus Monroy. Note that I can't figure out a decent way to search the Handbook at this point, but I'm open to ideas. -- Chris Costelloch...@calldei.com Stack Error: Lost on a cluttered desk... To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: poll() scalability
On Jul 07, 1999 at 01:10:38AM -0400, Zach Brown wrote: the sigio/siginfo model is a few orders of magnitude cheaper than poll/select as you scale the number of fds you're watching. The reasons for this being that select()/poll() have that large chunk of state to throw around every syscall, and the real world behaviour of very rarely ever returning more than than a few active pollfds Yes; that's effectively what the delta method I'm using now gets rid of; it only passes around state changes instead of the entire state. I agree that passing around the entire state is quite un-efficient; that's what I would like to get rid of. We just need to agree on a new method. with the sigio/siginfo model you register your interest in the fd at fd creation. from then on, when a POLL_ event happens on the fd we notice that it has an rt signal queue registered and a siginfo struct is tacked onto the end. these code paths can be nice and light. the siginfo enqueueing can be pointed at multiple queues by registering a process group with F_SETOWN, etc. Yes, but I also need support for temporarily de-registering interest in an fd, as well selectively choosing read/write/close events. its important to notice that we don't actually use signal delivery for this sigio/siginfo stuff, we mask the signal and use signwaitinfo() to block or pop the next siginfo struct off the queue. dealing with async signals jumping in would be annoying, and to do it right one would probably want to simply enqueue the siginfo delivered to the signal handler into a nice fifo that the real thread of execution would deal with.. instead of doing all this grossness, we just let the kernel maintain the siginfo queue. In this case, it doesn't seem all that different than a poll() type call, or an event queue that Peter was talking about. If the signal is blocked, then sigwaitinfo() effectively becomes a poll(), but with no timeout parameter. its quite like the 'delta poll' system proposed, but with differently inelegant semantics. I'd say if one were to design an event queueing/notification system and add a new api for it, we'd want to do it correctly from the get-go and lose the similarity to existing interfaces entirely unless they really makes sense to behave like them (which it doesn't in the poll() case, imho) I agree. One aspect of the design that should be explored is whether the new call should report events, or state. My current implementation reports state; (think of it as a level-triggered design), while the siginfo approach appears to be more of an edge-triggered design. I just looked at Banga's USENIX paper and they have a nice discussion of this issue. setup sigio and such on new fd (dorky, we have to do this in linux rather than inheriting it from the listening fd. but it has yet to show up on the profile radar, so, whatever :)) Hah. It showed up on my profiling; the kernel I'm running has routines so the child fd inherits certain settings from the parent. read() in the header (usually done in one read, but rarely will block and require falling back to a POLL_IN on the new fd) Well, we _NEVER_ want to block. Ever. And in my particular case, it is quite common for the header/data to be spread out over several reads. of course, this could change if you had a situation where you could burn through events like nothing else and simply couldn't deal with the lock-step.. Correct. I need this for a web caching proxy. The above loop won't work in my particular case. Also, I would guess that you would start getting into locking problems, and how to cancel a signal which has already been posted. locking problems? For asynchronous signal delivery, you alluded to this problem earlier as well. Since you're blocking signals, this isn't a problem. yes, the possibility of getting stale events in the queue is _annoying_. This is going to be a problem in any system that passes state deltas to the process in a queued manner. hacks could be put in, and perhaps should, to remove events in the queue for a fd when it is closed, etc. take the web server case again. it is quite possible to close() an fd while there is an event queued for it, and then accept() a new fd that now has a bogus event coming down the pipe for it. I get around this garbage in the cheesy web server by doing deferred close()s on fds based on the length of the queue when I stopped being interested in the fd (and as such turned off sigio delivery). Its gross. Exactly. Sometimes, we just want to close() an fd, even if there are pending events, and then immediately re-open with a new fd. Deferred closes are not an option. What I do at the moment is remove queued events/state when the fd is closed. (actually, my implementation sucks a bit, as I re-scan the state for this particular case).
Re: poll() scalability
On Mon, 5 Jul 1999, Jonathan Lemon wrote: Yes, but I also need support for temporarily de-registering interest in an fd, as well selectively choosing read/write/close events. yeah, this isn't terribly doable in the sigio/signal model. as you note later, this is indeed edge triggered so if you were to 'turn off' sigio on the fds for a bit, you might lose a state transition. this can be trivially accounted for in the userland code by receiving all events and filtering out the ones you aren't interested in, and thats what I currently do, but having a mask in the kernel might be more sensible. (as it turns out there are very few errant signals) In this case, it doesn't seem all that different than a poll() type call, or an event queue that Peter was talking about. If the signal is blocked, then sigwaitinfo() effectively becomes a poll(), but with no timeout parameter. in that its blocking, yes, but its the only thing we're blocking on in the event engine. thats the only way I can see that it is like poll() :) I agree. One aspect of the design that should be explored is whether the new call should report events, or state. My current implementation reports state; (think of it as a level-triggered design), while the the call should be able to do either, I'd guess. everything will be based around changes in state, regardless. the difference is wether you send those as units of work off to userland or if you toss them at an internal data structure that will then determine if the user cares about the resulting state. (so note that the 'level triggered' system could be built in user space code provided a 'edge triggered' kernel facility. some might argue taking this path) siginfo approach appears to be more of an edge-triggered design. I definitely.. Hah. It showed up on my profiling; the kernel I'm running has routines so the child fd inherits certain settings from the parent. that strikes me as odd.. these calls should be trivial when compared to other things that are going on.. the only annoying thing this does to the sigio/siginfo state machine is requiring an initial read() on the socket.. but as that almost always returns the request, its all right. read() in the header (usually done in one read, but rarely will block and require falling back to a POLL_IN on the new fd) Well, we _NEVER_ want to block. Ever. And in my particular case, it is quite common for the header/data to be spread out over several reads. this only blocks when there is no work to do :) what I was referring to up there was the read() returning EAGAIN and us waiting for the POLL_IN event on the socket to say that there is data ready.. Correct. I need this for a web caching proxy. The above loop won't work in my particular case. ?? works fine for me. (am getting 3500 reqs/second over a single thread over localhost with small files on an smp machine) Exactly. Sometimes, we just want to close() an fd, even if there are pending events, and then immediately re-open with a new fd. Deferred closes are not an option. What I do at the moment is remove queued events/state when the fd is closed. (actually, my implementation sucks a bit, as I re-scan the state for this particular case). the act of walking the queues could easily be more expensive than doing the defered close stuff if your queues are of respectable length. all the deferred close really does is add a latency to fd re-use, it doesn't significantly change the work involved.. Well, I'm sure that we have a lot of engineering talent around here. :-) :) I need to go give that paper a read.. -- zach - - - - - - 007 373 5963 To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Nothing. I just remember someone pointing out in a previous e-mail that all the core members had some sort of beard. Very few core members have beards, so whoever said that was wrong. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
It seems David Greenman wrote: A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Nothing. I just remember someone pointing out in a previous e-mail that all the core members had some sort of beard. Very few core members have beards, so whoever said that was wrong. Nah, are you sure ?? I havn't shaved in over a decade :) -Søren To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
It seems David Greenman wrote: A constant 5 o'clock shadow, maybe, but not a beard. And what's wrong with a beard? Nothing. I just remember someone pointing out in a previous e-mail that all the core members had some sort of beard. Very few core members have beards, so whoever said that was wrong. Nah, are you sure ?? I havn't shaved in over a decade :) Yes, I'm sure that all of the core members don't have beards (proven with just myself not having one). Although now that I think about it, about 25% of us do. This thread doesn't belong on hackers. -DG David Greenman Co-founder/Principal Architect, The FreeBSD Project - http://www.freebsd.org Creator of high-performance Internet servers - http://www.terasolutions.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
RE: Connect and so on..
On Mon, 28 Jun 1999, Ladavac Marino wrote: Essentially, we're trying to mediate system calls. Read, Write, Open, Socket calls from userland are caught, information about the calling process (i.e. caller UID) are sent to an external source for authorization and depending on the reply, the system call will proceed or not. This is the reason why the connection should be atomic and (so I think) in the kernel. Can't have other calls going through in the interim. [ML] If I understand this correctly, only the syscall which is being authenticated must block during the authentication. This makes the authentication atomic from the viewpoint of the syscall. The other processes/kernel supported threads may proceed. Sounds like RAGF(spelling?) scheme you're doing there. Sorry about tardy response, I've been away. What you describe above is correctly expresses what I was trying to say. Could you point me to more about this (RAGF) scheme? NFS daemon approach may be feasible for you, because this is exactly what it does. You have one central authentication daemon which is blocked in kernel syscall all the time, unless some other process (syscall) requests the authentication. The daemon then returns to user space, performs the neccessary authentication, and goes back into kernel with results. This is the way I would implement it, because it makes adding authentication schemes rather simple. [ML] /Marino Excellent, thank you. Although, looking through NFS code doesn't sound like fun. Oh well, time to pay my dues. Something else I need to look into is how to effeciently pass info back and forth from kernel space to user space and vice-versa. (See above for brief background of what I'm attempting to do). For every syscall being tracked/authenticated, a record is constructed and needs to be sent to the (userland) comms daemon that will send it to another server and await a response. In the mean time, the process making the syscall is blocked. Understandably this will really cut off process performance at the knees, but then again this a proof of concept project. One can easily imagine the processes being blocked starting to backup, since the comm daemon is competing for processor time, even if every entry into the kernel by (arbitrary) tracked syscalls resets the priority of the comms daemon to a higher level. (I'm trying to let the daemon get as much of the processor as possible to complete what it is doing. It releases it's quanta whenever it needs to wait for something). The comms daemon would keep a table of records received from the kernel to be authenticated, and only mark it as read when it has received a response (while being preempted many times), so that at the next arbitrary tracked syscall, the kernel would look at this table, look at all the status word fields (one per record) and read in the (response) records, if any, and mark these slots as unused for later use. This table would have to be in userland, with a single byte status field for every record. The table would have fixed size records, say 1k per entry. The seond field holds the PID and the third is free form. The status field would act as a signal to the kernel that a response was received. The kernel would read the status and PID and unblock the process, and either let the syscall proceed or not. Can't use a restart here, because, as I understand it, this would create another syscall, and hence a loop. Now, what I need to know is what is the best way to move this info over the fence, back and forth. Seems copyin() and copyout() are used throughout kernel code. With a table with fixed size records, I would simply need to loop through every status byte with copy*(addr + size(record)) to find out the responses, without (*ahem*) being interrupted. Is there an easier/better/more effecient subsystem to use that I don't know about? There are a lot of timing issues here, and I'm sure I've missed some. The comms daemon becomes a huge bottleneck for the processes that happen to make syscalls that are being tracked, but I don't see a better way. One of the things that the comm daemon would do is cache a lot of these recurring requests so that it wouldn't have to go outside to respond to the auth request. Also, if someone can point me to some books/papers/soliloquies of how to effeciently manage a shared table, I'd be grateful. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm script'
At that point the converstaion turned to talking about Irish soap carving and the fact that www.OpenBSD.org doesn't run OpenBSD. I guess I was wrong about IRC being positive. Well, you can blame the first bit of surrealism on jkh, the poor fella has some awful ideas about what the Irish do in their spare time. God bless him. Niall To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
I propose an rtfm(1) command, and I've got some Perl code that works. If people are interested, I will continue with it, and write a man page. [...] (-s = simple, don't search sections 3, 4, or 9, and 'e' means 'exact', or 'use whatis instead of apropos') If rtfm(1) is really for newbies and other clueless people, perhaps it should be made interactive. I mean, this whole idea sounds like it's geared towards people who wouldn't know what sections 3, 4, or 9 are. - 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: Pictures from USENIX
Don't ICBM coordinates require an elevation. BTW, I'm at 38.75N 76.87W for the lovely list :) 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: FreeBSD locations (was: Pictures from USENIX)
In message 3780fb62.96c77...@softweyr.com Wes Peters writes: : Oh lord, are we going to have to rename ourselves OzBSD now? ;^) We could have BoulderBSD, which would be 10MB surrounded by reality :-) There is also at least one OpenBSD committer in Boulder (aside from myself): Todd Miller. Warner P.S. For those of you unfamiliar with the poilical scene in Boulder, it has been summed up by the phrase Boulder, 10 square miles surrounded by reality. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
On Mon, Jul 5, 1999, Alex Zepeda wrote: I propose an rtfm(1) command, and I've got some Perl code that works. If people are interested, I will continue with it, and write a man page. [...] (-s = simple, don't search sections 3, 4, or 9, and 'e' means 'exact', or 'use whatis instead of apropos') If rtfm(1) is really for newbies and other clueless people, perhaps it should be made interactive. I mean, this whole idea sounds like it's geared towards people who wouldn't know what sections 3, 4, or 9 are. It'll probably have a lot of changes in the actual interface if people accept it as useful or not. I may have 'simple' (default to don't search 3, 4, and 9) on as default. -- Chris Costelloch...@calldei.com The computer is mightier than the pen, the sword, and usually, the programmer. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Budget on user-ppp
It could be nice with some sort of budget control in ppp. A few days ago I found out bb caused a dialup every 5 minutes. Today I found I had been online 27 hours uninterrupted. Some dialup-routers allows a setup of max a connects/b minutes online over c hours. Also, I know it is possible to have a longer and longer retry wait between unsuccessful calls, but this is (as far as I can see) not documented anywhere. (Except perhaps archives) Leif To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
docs/12377: doc patch for login_cap.
Hi folks, I'm unfamiliar with the ins and outs of the login_cap system. Could someone who is versed in it please take a look at this PR (text included) and let me know whether or not the suggested patch is correct. Thanks, N - Forwarded message from adr...@ubergeeks.com - From: adr...@ubergeeks.com To: freebsd-gnats-sub...@freebsd.org Subject: docs/12377: doc patch for login_cap. Number: 12377 Category: docs Synopsis: differences of a NULL login class need amplification Originator: Adrian Filipi-Martin Release:FreeBSD 3.2-RELEASE i386 Environment: stock 3.2 installation. Description: The fact that the root account has a different default login class is not well documented. It is documented, but only in passing in a paragraph low in the login_cap(3) manpage and in the login_cap.h header. The fact that the NULL login class has different interpretations depending upon the context of the capability lookup should be noted clearly or the behavior of the look up should be modified to make it more intuitive. The fact that the NULL class has two default values begs the question, is there really a default class? How-To-Repeat: N/A Fix: A quick fix is to apply the following doc patch. A better fix is to make all accounts with NULL login classes default to the default class and explicitly set root's class to 'root' in master.passwd. This would be an application of the principle of least surprise. *** login.conf.orig Thu Jun 24 10:24:22 1999 --- login.conf Thu Jun 24 10:25:22 1999 *** *** 60,65 --- 60,66 # # Root can always login # + # N.B. This is the default class for the root account, not 'default'. root:\ :ignorenologin:\ :tc=default: --- login_cap.3.origThu Jun 24 10:27:45 1999 +++ login_cap.3 Thu Jun 24 10:32:53 1999 @@ -139,14 +139,15 @@ .Fn login_getclass or .Fn login_getuserclass . -If the referenced user has no login class specified in +If the referenced user is not root and has no login class specified in .Pa /etc/master.passwd , the class name is NULL or an empty string, or if the class specified does not exist in the database, each of these functions will search for a record with an id of default, with that name returned in the .Ar lc_class -field. +field. If the user is root, then record with an id of root will +be returned instead of default. .Pp The .Ar lc_cap Release-Note: Audit-Trail: Unformatted: To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-doc in the body of the message - End forwarded message - -- [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
mmap question
I have a quick question about mmap, hopefully someone can smack me and point out what I'm missing :) the man page says: The mmap() function causes the pages starting at addr and continuing for at most len bytes to be mapped from the object described by fd, starting at byte offset offset. If len is not a multiple of the pagesize, the mapped region may extend past the specified range. Any such extension beyond the end of the mapped object will be zero-filled. Which is fine and dandy, I'll just stat() the file to get the filesize and mmap() it. But what happens in someone comes along and replaces the file with a larger file? I understand that my view of the file will change to the new file, but only the length that I mmap()ed originally. Do I have to periodically stat() the file to determine if I need to re-mmap() it should the file size change? And if so, doesn't that partly diminish the usefulness of mmap()? I mean, sure you can edit the file as a file and they are reflected in the in-memory image, but how many edits don't change the file size? Also, in case it hasn't been notice already (I'm running -stable from May 18th), the mmap(2) manpage has a typo: it has #include sys/mman.h Thanks for your help, 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: Repalcement for grep(1)
On Mon, 5 Jul 1999, Archie Cobbs wrote: Are you sure you're stripping out the newline and carriage return? You know, that did it. I'l put together another version tonight incorporating all the bug fixes and suggestions I have received over the past few days. More on that shortly. Jamie To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
CAM: delaying new commands during reset
The Iomega USB Zip drive is a bit slow when resetting (reset of the USB part of the drive). It takes 1s or more to reset. The reset is initiated because for example an illegal command was received (sync cache for example). umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) umass0: CBW 45: cmd = 10b (0x2500...), data = 8 bytes, dir = in umass0: Handling state 2, Bulk Data, TIMEOUT umass0: data-in 8b failed, TIMEOUT umass0: Bulk Reset (reset is now in progress and previous SCSI has been cancelled) umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) (CAM retries command) umass0: Busy, state 5, Bulk Reset (but gets told that the SCSI bus is busy) umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) (tries again) umass0: Busy, state 5, Bulk Reset (and is again told to go away, etc.) umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) umass0: Busy, state 5, Bulk Reset umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data) umass0: Busy, state 5, Bulk Reset (da0:umass0:0:1:0): got CAM status 0x3f (da0:umass0:0:1:0): fatal error, failed to attach to device (da0:umass0:0:1:0): lost device (da0:umass0:0:1:0): removing device entry The problem is that the reset is initiated and the command that failed xpt_done()-d with an error. scsi_da then retries the command, but it is returned instantly with a CAM_SCSI_BUSY error because the reset is still in progress. What would be the proper approach to make the ccb delay until the reset has finished? return a CAM_REQUEUE_REQ instead of CAM_SCSI_BUSY? Or store the ccb and process it when the reset is done? Thanks for any advice. Nick umass.c: http://www.etla.net/~n_hibma/usb/umass.c.new -- e-Mail: hi...@skylink.it To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
CAM panic in camq_fini
When, after attaching to the CAM later with cam_simq_alloc(1) cam_sim_alloc(action, poll, umass, sc, unit, 1, 0, devq) xpt_bus_register(sc-sim, 0) xpt_create_path(sc-path, NULL, cam_sim_path(sc-sim), CAM_TARGET_WILDCARD, CAM_LUN_WILDCARD) doing an immediate detach from it again, like so: xpt_async(AC_LOST_DEVICE, sc-path, NULL) xpt_free_path(sc-path) xpt_bus_deregister(cam_sim_path(sc-sim)) cam_sim_free(sc-sim, /*free_devq*/TRUE) (see also umass.c available at http://www.etla.net/~n_hibma/usb/umass.c.new after adding a call to umass_cam_detach right after umass_cam_attach). I get the following panic (frame #10): panic: free: address 0xdeadc0e2 out of range #0 0xc014b838 in boot () #1 0xc014ba85 in panic () #2 0xc012ea35 in db_panic () #3 0xc012e9d5 in db_command () #4 0xc012ea9a in db_command_loop () #5 0xc0130bfb in db_trap () #6 0xc021cc90 in kdb_trap () #7 0xc0228bb4 in trap () #8 0xc021ced3 in Debugger () #9 0xc014ba7c in panic () #10 0xc01482c6 in free () #11 0xc0122e22 in camq_fini () #12 0xc0122df5 in camq_free () #13 0xc012301e in cam_devq_free () #14 0xc01246db in cam_simq_free () #15 0xc0124785 in cam_sim_free () #16 0xc0209e46 in umass_cam_detach () #17 0xc0209067 in umass_detach () #18 0xc011d5eb in DEVICE_DETACH () #19 0xc01520c8 in device_detach () #20 0xc0151a6f in device_delete_child () #21 0xc0203836 in uhub_disconnect_port () #22 0xc020363f in uhub_explore () #23 0xc01ff45e in usb_discover () #24 0xc01ff192 in usbioctl () #25 0xc017e14c in spec_ioctl () #26 0xc017dab1 in spec_vnoperate () #27 0xc01e914d in ufs_vnoperatespec () #28 0xc0178441 in vn_ioctl () #29 0xc0157f43 in ioctl () #30 0xc02293f2 in syscall () #31 0xc021d5c0 in Xint0x80_syscall () #32 0x8048655 in ?? () It's pretty sure that it is not me doing anything nasty as the calls to attach and detach are virtually one after the other. Did I miss out on one of the deregister calls? One too many? On a sideline: the following is more consistent with the rest of the code: Index: cam_queue.c === RCS file: /home/ncvs/src/sys/cam/cam_queue.c,v retrieving revision 1.3 diff -u -r1.3 cam_queue.c --- cam_queue.c 1999/04/19 21:26:08 1.3 +++ cam_queue.c 1999/07/05 22:58:55 @@ -136,8 +136,9 @@ queue-entries * sizeof(cam_pinfo *)); free(queue-queue_array, M_DEVBUF); } - queue-queue_array = new_array-1; + queue-queue_array = new_array; queue-array_size = new_size; + queue-queue_array--; return (CAM_REQ_CMP); } Cheers, Nick To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
ICBM co-ords
On Mon, 5 Jul 1999, Brian F. Feldman wrote: Don't ICBM coordinates require an elevation. BTW, I'm at 38.75N 76.87W for the lovely list :) according to maps.yahoo.com, I'm at: lt=37.7954 ln=-122.4267 (san francisco) (it's in the url line when you look up an address and then click on the place you want the co-ords of.) (I forget who is collecting these) To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: CAM: delaying new commands during reset
I'm not sure what you mean by 'Busy' here, but it doesn't matter I
believe- the cam_periph_async called with
case AC_SENT_BDR:
case AC_BUS_RESET:
{
cam_periph_bus_settle(periph, SCSI_DELAY);
break;
}
should do bus settling for SCSI_DELAY. If you're not actually doing a bus
reset, you need to hold off the command with a requeue but only if you
tell it when it can go (I believe- I sure wish Justin would document this
stuff).
On Tue, 6 Jul 1999, Nick Hibma wrote:
The Iomega USB Zip drive is a bit slow when resetting (reset of the USB
part of the drive). It takes 1s or more to reset. The reset is initiated
because for example an illegal command was received (sync cache for
example).
umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data)
umass0: CBW 45: cmd = 10b (0x2500...), data = 8 bytes, dir = in
umass0: Handling state 2, Bulk Data, TIMEOUT
umass0: data-in 8b failed, TIMEOUT
umass0: Bulk Reset
(reset is now in progress and previous SCSI has been cancelled)
umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data)
(CAM retries command)
umass0: Busy, state 5, Bulk Reset
(but gets told that the SCSI bus is busy)
umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data)
(tries again)
umass0: Busy, state 5, Bulk Reset
(and is again told to go away, etc.)
umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data)
umass0: Busy, state 5, Bulk Reset
umass0: XPT_SCSI_IO 0:1:0 command: 0x25 (10b command/8b data)
umass0: Busy, state 5, Bulk Reset
(da0:umass0:0:1:0): got CAM status 0x3f
(da0:umass0:0:1:0): fatal error, failed to attach to device
(da0:umass0:0:1:0): lost device
(da0:umass0:0:1:0): removing device entry
The problem is that the reset is initiated and the command that failed
xpt_done()-d with an error. scsi_da then retries the command, but it is
returned instantly with a CAM_SCSI_BUSY error because the reset is
still in progress.
What would be the proper approach to make the ccb delay until the reset
has finished? return a CAM_REQUEUE_REQ instead of CAM_SCSI_BUSY? Or
store the ccb and process it when the reset is done?
Thanks for any advice.
Nick
umass.c: http://www.etla.net/~n_hibma/usb/umass.c.new
--
e-Mail: hi...@skylink.it
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: 'rtfm' script
On Mon, Jul 05, 1999 at 05:11:57AM -0500, Chris Costello wrote: I've been encountering people recently who, for one reason or another, are unable to find information for themselves when they have a question on FreeBSD. I propose an rtfm(1) command, and I've got some Perl code that works. If people are interested, I will continue with it, and write a man page. The source is attached. It would be good if you could use fetch(1) instead of forming the HTTP request yourself. That way people who already have fetch working through proxies don't have to modify anything to use rtfm. Is there a particular reason you're writing it in perl? Joe To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Replacement for grep(1) (part 2)
Due to the number of fixes I have received over the past few days, I decided to put together a new release of grep. It was either this or watch _Titanic_ on Cinemax. I incorporated a huge patch from Dag-Erling Smorgrav which as he put it cleaned it up to make it conform to FreeBSD's coding style standards. I also removed a bunch of unused or unnecessary variables, fixed one or two minor bugs, and made a few entirely subjective cosmetic improvements. He also modified the Makefile to generate links for fgrep and egrep as well. All things I was going to worry with when it was done. :) I added the links for zgrep. I changed the sample length in the binary checker from 64 bytes to 32 at his suggestion. This is the same as how GNU grep handles it. I changed it so that even when called as grep or with -G, it treats the pattern as an extended regular expression. GNU grep behaves the same way. Simon Burge sent code to enable -w as well as several smaller code fixes and clean ups. I changed bin_file() and seekable() to operate on a pointer to a FILE rather than on an integer file descriptor. Due to popular demand, I added support for searching gzip compressed files. GNU grep only supports searching gzip compressed files. It did not bloat my code as much as I expected; I vapor locked and forgot about libz, which did all the hard work for me. It would be trivial to add support for bzip and bzip2 files for those OSes that have libbz2. Archie Cobbs dropped the hint needed to solve the problems with -x. Right now, I wrap the pattern with ^( and )$. I know GNU grep does this, but is this correct? Now, as it stands, I beleive this implementation is identical to GNU grep, except for the added -o option, and the -A num, -B num, -C, and -num family of options. Despite what I said before, I will implement them. Another popular demand thing. So I will take care of that over the next few days. It would be really swank if someone were to go over what I have and make sure it is correct. I know I was blowing $ before, and I think that is correct now. Due to problems with the previous download site (it is down as I type this), I will place this file in two locations: ftp://dragon.ham.muohio.edu/pub/howardjp/grep-0.3.tar.gz ftp://ftp.wam.umd.edu/pub/howardjp/grep-0.3.tar.gz It will probably be slow to hit the second, as it may be down until tomorrow morning. Thank you everyone who helped, Jamie To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
On Mon, Jul 5, 1999, Joe Abley wrote: On Mon, Jul 05, 1999 at 05:11:57AM -0500, Chris Costello wrote: I've been encountering people recently who, for one reason or another, are unable to find information for themselves when they have a question on FreeBSD. I propose an rtfm(1) command, and I've got some Perl code that works. If people are interested, I will continue with it, and write a man page. The source is attached. It would be good if you could use fetch(1) instead of forming the HTTP request yourself. That way people who already have fetch working through proxies don't have to modify anything to use rtfm. Is there a particular reason you're writing it in perl? Mostly regexp and such. If I can figure out how to use the regexp code for C, I'd probably rewrite it. Joe -- Chris Costelloch...@calldei.com The generation of random numbers is too important to be left to chance. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
I've added texinfo searching and made it use fetch(1) instead for those behind proxies. Is there any word as to whether this might be imported into the actual tree or if I should just make it a port? -- Chris Costelloch...@calldei.com Machine independent code isn't. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
The updated version (with support for texinfo searching, and use of fetch(1)) is availible at http://www.calldei.com/~chris/rtfm.pl -- Chris Costelloch...@calldei.com It is now pitch dark. If you proceed, you will likely fall into a pit. To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: support for i386 hardware debug watch points
Jonathan Lemon writes: In article local.mail.freebsd-hackers/199907041453.kaa03...@dean.pc.sas.com you write: This is not as efficent as it could be implemented with a separate flag to indicate whether saving the debug registers is necessary since loading/storing the debug registers is fairly expensive (11 clocks on an i486). Yes; you may want to just use another bit in pcb_flags that indicates if the debug registers are in use. OK, I did that. What is the convention for naming the flags? The only one in use for that set of flags is FP_SOFTFP. I'm currently using PCB_DBREGS, but I but I easily change the name to whatever convention dictates - please advise. Should 'struct reg' be extended to directly include the debug registers or should we go the route of having another data structure for the debug registers, not unlike how the floating point registers are handled? I'd be inclined to create another data structure, unless the debug registers are architecturally defined to be identical on all x86 chips. Otherwise, I think I will need to set up a 'struct dbregs', provide the appropriate 'fill_dbregs()' and 'set_dbregs()', and then provide a PT_SETDBREGS, PT_GETDBREGS interface to 'ptrace()'. Either that, or create a routine like i386_set_breakpoint() in sys_machdep that would handle setting breakpoints for different types of cpu architectures. What I ended up doing is make a new struct dbregs, similar to struct fpregs. Additionally, I modified the necessary procfs code to create a view to read and write the registers called dbregs. The only thing that concerns me here is that maybe this entry in procfs is too architecture dependent, or maybe it violates some standards regarding procfs semantics (if there are any). I don't know enough about the Alpha architecture to know if this entry makes sense or not. Any comments here are appreciated. It appears as though some other systems do this with an ioctl call using the fd to the /proc/$pid/ctl file. However, these semantics seem to go against the precedent set by the ./regs and ./fpregs interfaces. I chose to use ./dbregs primarily because it was consistant with the use of ./regs and ./fpregs. Again, comments here are appreciated. I've got this kernel running right now and everything seems to be working fine, at least no panics or smoke. Here's a question: Are there any security concerns with being able to update the debug registers? Should a process be able to set a breakpoint inside the kernel, for example? In such a case, an INT 3 exception would be generated from within kernel code. Would this drop the system into the kernel debugger if it was enabled? If I've implemented the saving and restoring (and clearing) of the debug registers in cpu_switch() the way that I have intended, a watchpoint that a process sets within the kernel should not be able to occur outside the context of the process in which it was set. However, it is conceivable that a user (if allowed to put a breakpoint outside of his address space) could force the kernel to be interrupted at any location that could execute within the context of his process. This could result in breaking into code that was never designed to be interruptible, such as in the middle of updating a shared data structure. Any ideas are welcome, and I will do my best to implement them. Now that I've done this much, I now need to look at gdb some more and hook in the new interface. I'll follow that up with additional testing. Thanks, -Brian -- Brian Dean SAS Institute Inc brd...@unx.sas.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
On Mon, 5 Jul 1999, Chris Costello wrote: If rtfm(1) is really for newbies and other clueless people, perhaps it should be made interactive. I mean, this whole idea sounds like it's geared towards people who wouldn't know what sections 3, 4, or 9 are. It'll probably have a lot of changes in the actual interface if people accept it as useful or not. I may have 'simple' (default to don't search 3, 4, and 9) on as default. This sounds like a good idea. Now, ideally, I'd love to see something that could take an english phrase and figure out where to go from there. Sort of like an Ask Jeeves (ask.com) for FreeBSD newbies. This is not to say that the more advanced options wouldn't be useful; I could personally find a use for something to search the handbook, FAQs and man pages at once. I think I'll volunteer a few of my newbie friends once this progresses a bit further. P.S. If you're looking for an easy to use regexp implementation, and aren't afraid of C++, check out Qt; if you're looking for more of a challenge, there's always the need for an rtsl(1) ;) - alex To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: 'rtfm' script
On Mon, 5 Jul 1999, Alex Zepeda wrote: P.S. If you're looking for an easy to use regexp implementation, and aren't afraid of C++, check out Qt; if you're looking for more of a challenge, there's always the need for an rtsl(1) ;) rtsl(1) = glimpse(1) : - 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: Budget on user-ppp
It could be nice with some sort of budget control in ppp. A few days ago I found out bb caused a dialup every 5 minutes. Today I found I had been online 27 hours uninterrupted. Some dialup-routers allows a setup of max a connects/b minutes online over c hours. Patches are always welcome ;-) Also, I know it is possible to have a longer and longer retry wait between unsuccessful calls, but this is (as far as I can see) not documented anywhere. (Except perhaps archives) ? How about under ``set redial'' in the man page ? set redial secs[+inc[-max]][.next] [attempts] ppp can be instructed to attempt to redial attempts times. If more than one phone number is specified (see ``set phone'' above), a pause of next is taken before dialing each number. A pause of secs is taken before starting at the first number again. A literal value of ``random'' may be used here in place of secs and next, causing a random delay of between 1 and 30 seconds. If inc is specified, its value is added onto secs each time ppp tries a new number. secs will only be incremented at most maxinc times. maxinc defaults to 10. Note, the secs delay will be effective, even after attempts has been exceeded, so an immediate manual dial may appear to have done nothing. If an immediate dial is required, a ``!'' should immediately follow the ``open'' keyword. See the ``open'' de- scription above for further details. (Hmm, I'd better change maxinc - max !) Leif -- Brian br...@awfulhak.orgbr...@freebsd.org http://www.Awfulhak.org br...@openbsd.org Don't _EVER_ lose your sense of humour ! br...@freebsd.org.uk To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
Re: Pictures from USENIX
Frivolous is to have a page with pics from Ulf's Partys and play Spot The Devloper. Stefan On Sun, 4 Jul 1999, Jordan K. Hubbard wrote: I'm going to have a core team page worked on which has pictures and brief bios, perhaps something by next week. Such things may seem frivolous, but I it helps people relate a little more directly to the core team if they can see what they look like and read a bit about them. Same for the committers group, but at 165+ members that's going to be a somewhat larger, long-term project. :-) - Jordan On Sun, 4 Jul 1999, Wilko Bulte wrote: Which makes a good case for a permanent picture gallery @ www.freebsd.org I guess. I can donate a bunch of pictures taken at last year's hackersparty here in the Netherlands. When FreeBSDcon comes closer, I'll probably be be asking which of the developers are coming to it. I'm going to try to get some large group photos etc etc. - 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 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: mmap question
: Which is fine and dandy, I'll just stat() the file to get the filesize and :mmap() it. But what happens in someone comes along and replaces the file :with :a larger file? I understand that my view of the file will change to the new :file, but only the length that I mmap()ed originally. Do I have to :periodically stat() the file to determine if I need to re-mmap() it should :the file size change? And if so, doesn't that partly diminish the usefulness :of mmap()? I mean, sure you can edit the file as a file and they are :reflected in the in-memory image, but how many edits don't change the file :size? You can mmap() an area that is larger then the file. For example, you could mmap a 100 bytes file into a 32MB area. If the file then grows, you can access the new data up to the amount of space you reserved. However, accessing pages beyond the file EOF via the mmap() will result in a segfault. This is also true if a file is truncated out from under you - previously valid data pages will disappear. If you mmap() the exact size of a file and the file grows, you have to mmap() the new area of the file or unmap the old area and remap the entire file to gain access to the additional data. You can mmap() areas of a file in a piecemeal fashion though this should not be taken to extremes since it will slow down page-fault handling. Most programs using mmap() use it on files which are not expected to change out from under the program's control. Thus most programs using mmap() simply map the file's full size and do not try to do anything fancy. : Kelly : ~kby...@posi.net~ -Matt Matthew Dillon dil...@backplane.com To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
IPv6 and FreeBSD
Found this on slashdot. http://www.infoworld.com/articles/hn/xml/990705hn3com.xml There is a link to www.ipv6.org which lists IPv6 implementations. FreeBSD is listed as well as Linux, OpenBSD, and NetBSD. Linux ships with IPv6, OpenBSD will ship it's next version with IPv6. Any idea what the current status of our IPv6 implementation ? Josef -- Josef Grosch | Another day closer to a |FreeBSD 3.2 jgro...@mooseriver.com | Micro$oft free world | UNIX for the masses To Unsubscribe: send mail to majord...@freebsd.org with unsubscribe freebsd-hackers in the body of the message
