Re: optimizing apache with php and nfs mounts
On Tue, Mar 13, 2001 at 12:51:19PM -0800, Alfred Perlstein wrote: Well... when you 'gzip -9' something, it just takes longer, it doesn't sometimes corrupt your data (afaik). Hmm. gzip seems to be pretty good about those things. I guess it's one of the few GNU programs to be that way. :^) So it sort of makes sense for people to assume that when the compiler advertises certain things that it's going to do it perhaps not in the most effecient manner, but at least correctly. Yes, hello pipe dream. However, even the pgcc web page describes -O2 as safe. I guess I'll be playing around to see which bits generate incorrect code soon, since this is all so tempting. What just popped into my mind was that maybe some sort of check for stuff like "-fomit-frame-pointer" in CFLAGS should be made in buildworld, since it will cause failure if you build profiling libs. Other thoughts include how -O2 is bombing out make world. I know in my dealings with kde I've had lots of trouble getting gcc to emit decent debug info (depending on the code, -gstabs+, -ggdb3, etc would spit out internal errors). SO are the gcc developers i imagine. :) Pfft. Damnit I want software that I don't have to pay for, to work perfectly every time, and that I don't have to contribute to erm.. Yes, scanning thru the ML leads me to believe some of these optimizations are pretty much untested. Which is kinda funny, since the ia32 bits are the most used ones or so it seems. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: optimizing apache with php and nfs mounts
On Wed, Mar 14, 2001 at 01:19:31AM -0800, Alex Zepeda wrote: However, even the pgcc web page describes -O2 as safe. I won't even to there... Yes, scanning thru the ML leads me to believe some of these optimizations are pretty much untested. Which is kinda funny, since the ia32 bits are the most used ones or so it seems. Not untested -- but you should go grab a graduate text on compiler optimizations and familiarize yourself with the complexity of the problem. If hello_world.c showed a problem with an optimization, I guarantee it would be fixed. The current test case of holding up the entire FreeBSD kernel as showing an optimization problem doesn't cut it. If you care to trim it down to a single module showing the problem -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
-On [20010310 01:00], Lyndon Nerenberg ([EMAIL PROTECTED]) wrote: Perhaps a first step towards leaning on the vendors for documentation is to publically declare our support for those vendors who *do* release documentation under reasonable terms. One way to do this is to acknowledge those vendors in the hardware section of the handbook, and encourage people to support them by buying thier products. That's what Soeren and me did. HighPoint was very forthcoming with documentation and as part of that synergy they put the FreeBSD Hardware logo on their frontpage http://www.highpoint-tech.com and us mentioning it on our webpages as well as being a primary recommendation over other vendors back when we got little information out of other vendors. -- Jeroen Ruigrok van der Werven/Asmodai .oUo. asmodai@[wxs.nl|freebsd.org] Documentation nutter/C-rated Coder BSD: Technical excellence at its best D78D D0AD 244D 1D12 C9CA 7152 035C 1138 546A B867 What is history but a fable agreed 'pon? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
OP make import?
Dear All, In the interest of a unified BSD ports tree, is anyone working to integrate the diffs for the make from openpackages into the FreeBSD codebase? Kees Jan You are only young once, but you can stay immature all your life. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ecc kld for FreeBSD 4.2
On Tue, 13 Mar 2001, Chris Sears wrote: THANKS! and compliments on your name. It was a quick and simple port to see if people were interested. I've sent it to the author/maintainer Dan Hollis but I haven't gotten a response yet. He has an email list on Yahoo/Groups and there is occasional traffic so it isn't dead code. I'm sure there would be much interest, especially since FreeBSD is run on many systems with ECC memory subsystems. I, for one, don't build a server without ECC memory and a chipset that does auto-correction/scrubbing. It would be taboo. Even my workstations have it. :-) Yes, I did notice that there was no licensing. I will broach that with him. I can live with GPL since I see this as being a KLD which can be installed from source. But I prefer BSD. Since not everybody would want to use a module, or even could use a module, a BSD license would be ideal so that it could be compiled directly into the kernel. It is entirely up to the author what he wants to use, of course. DEV_MODULE vs DRIVER_MODULE. It is true that DEV_MODULE is much less common but it is minimally sufficient. If it were a DRIVER_MODULE, then it would just be allocating a bunch of structures and entry points and noop'ing them out. But perhaps someone else could lend an opinion. Looking at the differences, DEV_MODULE did look quite a bit easier to use. :-) Thanks for the 440BX patch, I'll add it. As far as the ServerWorks III chipset, the necessary documentation has *not* been available. I think they are a small company and a little paranoid WRT intellectual property. If you have it, or if you can get it, this would be great. It wasn't really a 440BX-related patch, just some pretty-print information when the module was loaded, some of which is probably irrelevant and could be removed (such as the SBE/MBE stuff). Just saying that the ECC module was loaded was a little bit too light on the information side. :-) On a similar note, how can we go about getting similar run-time information out of this, such as the current count of SBEs and MBEs? Some sysctls perhaps? The current code uses procfs under Linux, but that seems ugly to me. Basically, I would like to break the file into Linux, BSD and ecc sections. This would simplify things for the author who has expressed interest in a kernel patch as well as a module. The reason for kernel was that module support can be config'd out on Linux. I talked to Daniel O'Connor on IRC, and he mentioned he would like to clean it up a bit. Splitting it into OS-specific and OS-independant parts would be a good idea, I think. I'm not sure how kld's are distributed as there don't seem to be any in the ports collection. And I wouldn't mind cleaning it up a bit. Actually, I can think of at least two -- ports/emulators/rtc, depended on by the ports/emulators/vmware2 port, which has yet another kernel module in it. -- Chris Dillon - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The fastest and most stable server OS on the planet. For IA32 and Alpha architectures. IA64, PPC, and ARM under development. http://www.freebsd.org To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
At 06:35 AM 03/14/2001, Jeroen Ruigrok/Asmodai wrote: -On [20010310 01:00], Lyndon Nerenberg ([EMAIL PROTECTED]) wrote: Perhaps a first step towards leaning on the vendors for documentation is to publically declare our support for those vendors who *do* release documentation under reasonable terms. One way to do this is to acknowledge those vendors in the hardware section of the handbook, and encourage people to support them by buying thier products. Typically companies that are quick to release docs are the weaker companies, because they need sales or dont have a clear target market. Plus the best technologies are usually proprietary at least in the beginning of their deployment. So your strategy will guarantee alignment with many mediocre products and few of the best, which doesnt seem to be in the best interests of anyone. Telling people that they cant use Intel or 3com cards will more likely drive them to other OSes then hurt either of the fore mentioned companies. A better strategy would be to welcome ALL vendors AND binary distributions (who may release source under NDA if they chose) so that the best products could be available for FreeBSD without the adversity of the "geek-revolution" that you propose. That's what Soeren and me did. HighPoint was very forthcoming with documentation and as part of that synergy they put the FreeBSD Hardware logo on their frontpage http://www.highpoint-tech.com and us mentioning it on our webpages as well as being a primary recommendation over other vendors back when we got little information out of other vendors. I'm sure that High-point's competitors are shivering in their boots over this powerful alliance. DB Emerging Technologies, Inc. - http://www.etinc.com ISA and PCI T1/T3/V35/HSSI Cards for FreeBSD and LINUX Multiport T1 and HSSI/T3 UNIX-based Routers Bandwidth Management Standalone Systems Bandwidth Management software for LINUX and FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
* Dennis [EMAIL PROTECTED] [010314 08:14] wrote: A better strategy would be to welcome ALL vendors AND binary distributions (who may release source under NDA if they chose) so that the best products could be available for FreeBSD without the adversity of the "geek-revolution" that you propose. I don't know about that: how many times does windows crash because of poorly written drivers rather than flaws in the core OS? (*) how many hardware vendors say "sure dude, just buy _any_ disk and stick it in my SAN box, we'll still support you!" (*) win9x has a "feature" they expect thier driver coders to be brain dead enough to exhaust the kernel stack (either that or the driver arch demands this), they have a guard page on the stack that catches overruns and performs a "fixup" do a search on "MinSP" (maybe plural) to see what I mean. -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
At 11:32 AM 03/14/2001, you wrote: Dennis wrote: At 06:35 AM 03/14/2001, Jeroen Ruigrok/Asmodai wrote: -On [20010310 01:00], Lyndon Nerenberg ([EMAIL PROTECTED]) wrote: Perhaps a first step towards leaning on the vendors for documentation is to publically declare our support for those vendors who *do* release documentation under reasonable terms. One way to do this is to acknowledge those vendors in the hardware section of the handbook, and encourage people to support them by buying thier products. Typically companies that are quick to release docs are the weaker companies, because they need sales or dont have a clear target market. Plus the best technologies are usually proprietary at least in the beginning of their deployment. So your strategy will guarantee alignment with many mediocre products and few of the best, which doesnt seem to be in the best interests of anyone. Telling people that they cant use Intel or 3com cards will more likely drive them to other OSes then hurt either of the fore mentioned companies. A better strategy would be to welcome ALL vendors AND binary distributions (who may release source under NDA if they chose) so that the best products could be available for FreeBSD without the adversity of the "geek-revolution" that you propose. I think you underestimate the number of faceless servers thoughout the world running FreeBSD or Linux. The jobs they do aren't glamourous, but they have to be done (cheap), so they don't get the front page accolades that Sun UE10ks get, but they do get used. My point is that it will have no impact, so you will only hurt the FreeBSD community. You cant strong-arm companies into making their intellectual properly rights publicly available. its a losing argument. That's what Soeren and me did. HighPoint was very forthcoming with documentation and as part of that synergy they put the FreeBSD Hardware logo on their frontpage http://www.highpoint-tech.com and us mentioning it on our webpages as well as being a primary recommendation over other vendors back when we got little information out of other vendors. I'm sure that High-point's competitors are shivering in their boots over this powerful alliance. Probably not, but they might wonder why High-points sales are stronger than they should be, and why there is so much positive material about High-point cards on the web (while their own cards are barely mentioned). People who want to get work done don't want to mess with a company that tries to stop them (by not releasing specs or drivers for the OS you're using) and will instead go with the open-minded competetor. selling to geeks is not most companies marketing strategy. What you fail to understand is the negative impact on sales when some taiwanese company clones the hardware and you effectively end up cannibalizing your own business with your efforts. Your also just as likely to get negative press because the guy that writes the driver for your hardware does a lousy job, and the resulting driver sucks and people then think your hardware sucks because most geeks can't separate the hardware from the driver. Your logic is backwards. You think that rewarding mediocre companies will scare good companies into wanting a piece of the pie. The only thing that it will do is consume these companies so that the good companies can have a larger share of the more profitable sun/NT market, and convince them that they want no part of the "free" market if they have to compete with cut-rate hardware from hungry companies. Driving away companies with good products because you dont like their policies is counterproductive. the only reason people use windows is because of their relationships with vendors who sell products that people want. its not about the OS, its about what you can do with it. dennis To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
* Dennis [EMAIL PROTECTED] [010314 09:21] wrote: At 12:09 PM 03/14/2001, Alfred Perlstein wrote: * Dennis [EMAIL PROTECTED] [010314 08:14] wrote: A better strategy would be to welcome ALL vendors AND binary distributions (who may release source under NDA if they chose) so that the best products could be available for FreeBSD without the adversity of the "geek-revolution" that you propose. I don't know about that: how many times does windows crash because of poorly written drivers rather than flaws in the core OS? (*) Im not sure of what the difference is. There are many poorly written drivers in FreeBSD and linux also. The fact that you have source may be soothing, but it doesnt help the 99% of people that cant fix it themselves. At least we can point at the driver and call it a honking bunch of poo rather than allowing the blame to hit the core OS. Honestly, I'd love to see vendors able to work out shipping drivers for FreeBSD, even in binary form, it would make users happy. I would just be pretty hard pressed to use them though. :) -- -Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]] Daemon News Magazine in your snail-mail! http://magazine.daemonnews.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: systat -vmstat or iostat IO help
:It will use all available memory for disk caching if possible, but it :only caches things you've accessed at least once so I would say you :simply haven't accessed more then 650MB or so worth of file data. : :Is it correct to say that cached file data (file content) :is taken into account in Active/Inactive/Cached page counters if and only if :accessed through the mmap interface? What does it happen when a process :access file data through the filesystem interface (open/read/close)? It doesn't matter how the data is accessed... either through read/write or mmap, it will be cached the same in the system. FreeBSD does have a sequential detection heuristic and will attempt to throw away data earlier that it believes will not be accessed again soon, but the heuristic is implemented both for the VM system (mmap) and for read/write so there actually isn't much of a distinction between the two. :Is it correct to say that in this case the Buffer counter gives you :the detail on how much file data is cached? :This should be how the old 4.4BSD works FreeBSD has what is known as a 'unified buffer cache', as you note below. This means that the data mapped by the buffer cache is in fact the same data in the VM page queues, without any duplication. The buffer cache can be thought of as a 'quick lookup' mechanism, making it easier for the kernel to manipulate file data and also holding file block - disk block translations for the I/O subsystem. If a data buffer is not in the buffer cache it may still be in the VM page queues. The buffer cache is typically limited to a few dozen megabytes worth of mappings. The VM page queues are not limited in any way. So even though the buffer counter might indicate that, say, 20MB of data is in the buffer cache, you could still really have hundreds of megabytes of cached file data in the VM page queues. The buffer counter does not really represent anything. :I know that the buffer cache management has been merged with :the paging system in FreeBSD but I do not know if the above :statements still hold true. : : Thanks : Paolo : :P.S. Matt, your mentoring job is invaluable :) Heh. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
aout assembler: anybody still cares about it?
greet. anybody? I end up compilling kde2.1 on 2.2.x with few strange sigsegv from the aout assembler. I took the hint and try to repeat the same manner using 4.x and -CURRENT Seems like it's deal with pic generated code. ( /usr/libexec/aout/as , using gcc-2.95.2 and egcs-1.1.2 ) I already fix it , (expr.c and tc-i386.c from /usr/src/gnu/usr.bin/as so , anybody cares about it? (go away aout!) http://www.hobbiton.org/~skywzrd/FreeBSD-as pic generated test from cc -S (perhaps the patch is questionable) anyway, 2.2.x still survive , even with kde-2.1 regards To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
You cant strong-arm companies into making their intellectual properly rights publicly available. its a losing argument. Strange, in that it worked for a number of video-card vendors when XFree86 either dropped support and/or never supported the card in question. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ecc kld for FreeBSD 4.2
Mike (and Paul) I'm fixing this so that it doesn't use the 2.x PCI compatibility interface; there's a lot of other real ugliness in here, some of which is probably worth throwing out. I'm not exactly sure what you meant here. Do you mean the pci_readcfg calls? I thought they were low-level rather than compatibility. If not that, what? The lack of an NMI handler is actually really poor, but fortunately, easy to deal with. Linux has the same problem: adding an NMI handler from a module is a little tricky. It has been on the TODO list. If logging the ECC NMI (sans address) is sufficient, then the ECC NMI handler could be made generic and can be written/check-in in parallel with this effort. (In fact, I think that minimal patch should be done now.) Otherwise you have to install a more specific handler. In any case, I want to see Paul Saab's code. There's a decision to be made here with regards to this code. If it's OK to relicense it under the BSDL, it should be integrated with the i386 hostbridge code (ie. not a KLD at all). If we do that, tracking the Linux module is going to be a little bit more work (but not a lot). If it's not OK, then it'll need to be maintained separately (or rewritten, which wouldn't be too hard). Yuck, I hate dueling license issues but I guess I've signed up for this. I'll contact/work with Dan Hollis about this. I'm somewhat bi-lingual. At any rate, I'll contact you once I've fixed the attachment code; it's pretty simple. You might also want to talk to Paul Saab ([EMAIL PROTECTED]) who has ECC code for FreeBSD already, including some NMI support. I looked in ~ps but unfortunately didn't see anything ECC related. But I will send him a note. In fact, I'll copy him on this. thanks, Chris To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OP make import?
On Thu, Mar 15, 2001 at 01:46:16AM +1300, Dan Langille wrote: On 14 Mar 2001, at 13:23, Koster, K.J. wrote: In the interest of a unified BSD ports tree, is anyone working to integrate the diffs for the make from openpackages into the FreeBSD codebase? I think people might be waiting for us go get to the point where our work is actually usable. Also, I believe that Will Andrews has expressed a firm desire to do this. IIRC, his fingers have been in make lately. ==ml -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
On Wed, Mar 14, 2001 at 11:37:34AM -0800, Alfred Perlstein wrote: ALL the time. Microsoft has given the UC-Davis security and formal verification lab a multi-year grant to look at this problem. (the approach being researched is "model checking") How does one get the forms for these sort of grants? :) Write white paper, submit to M$. Or network at conference, have M$ friend tell you a proposal would be meet open arms. The typical University/research way of getting [commercial] grants. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Upgrade gone BAD!
Hey not sure this is the right list but here we go: bladerunner:~ $ftp ftp.freebsd.org Bad system call (core dumped) keeps comming with most commands after i used the 4.1-REL - 4.x-STABLE upgrade kit - any ideas how to salvage this system ? Michael Aronsen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
At 02:31 PM 03/14/2001, Jeroen Ruigrok/Asmodai wrote: -On [20010314 17:38], Dennis ([EMAIL PROTECTED]) wrote: At 06:35 AM 03/14/2001, Jeroen Ruigrok/Asmodai wrote: That's what Soeren and me did. HighPoint was very forthcoming with documentation and as part of that synergy they put the FreeBSD Hardware logo on their frontpage http://www.highpoint-tech.com and us mentioning it on our webpages as well as being a primary recommendation over other vendors back when we got little information out of other vendors. I'm sure that High-point's competitors are shivering in their boots over this powerful alliance. Well Dennis, I congratulate you. Be assured that with this attitude you just displayed you made me decide never to recommend ET Inc., for any of my present and future projects. Clearly you dont get it. Its like teaching a fish to fly. LOL To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
At 01:47 PM 03/14/2001, you wrote: On Wed, Mar 14, 2001 at 09:09:15AM -0800, Alfred Perlstein wrote: how many times does windows crash because of poorly written drivers rather than flaws in the core OS? (*) ALL the time. Microsoft has given the UC-Davis security and formal verification lab a multi-year grant to look at this problem. (the approach being researched is "model checking") Why would they need to do that? Every time you load a program it updates the libraries, breaking older programs. Its a philosophical problem. You dont need a grant to figure it out. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
At 02:31 PM 03/14/2001, Jeroen Ruigrok/Asmodai wrote: -On [20010314 17:38], Dennis ([EMAIL PROTECTED]) wrote: At 06:35 AM 03/14/2001, Jeroen Ruigrok/Asmodai wrote: That's what Soeren and me did. HighPoint was very forthcoming with documentation and as part of that synergy they put the FreeBSD Hardware logo on their frontpage http://www.highpoint-tech.com and us mentioning it on our webpages as well as being a primary recommendation over other vendors back when we got little information out of other vendors. I'm sure that High-point's competitors are shivering in their boots over this powerful alliance. Well Dennis, I congratulate you. Be assured that with this attitude you just displayed you made me decide never to recommend ET Inc., for any of my present and future projects. Im sure that we will survive quite nicely without your recommendations. DB To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: optimizing apache with php and nfs mounts
On Wed, Mar 14, 2001 at 02:58:40AM -0800, David O'Brien wrote: I won't even to there... Well, the only reason I mentioned it.. was that the pgcc folks don't seem to be too delusioned about the dangers. -ON (N 2) is regarded as at least possibly in danger of generating incorrect code. Not untested -- but you should go grab a graduate text on compiler optimizations and familiarize yourself with the complexity of the problem. Care to recommend any starting places. You've piqued my interest. If hello_world.c showed a problem with an optimization, I guarantee it would be fixed. Of course depending on the problem. The current test case of holding up the entire FreeBSD kernel as showing an optimization problem doesn't cut it. If you care to trim it down to a single module showing the problem Well I've just made buildworld with CFLAGS = "-O2 -march=pentiumpro -malign-double" from a world built with the same flags. Not so sure of any performance impact however. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
On Wed, Mar 14, 2001 at 02:41:53PM -0800, Kent Stewart wrote: With 2000 and above, your system will check for non-digitally signed dll's and etc. Being signed has nothing to do with correctly working. The project I was speaking about wanted to be able to do something about you buying that wonderful new video card, or ATA-100 card -- receving the vendor's device driver and finding it decreases the stability of your system. Windows has a specification and convention of how drivers should be written. How do you know some driver actually follows it? That is the basic problem this grant is researching. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: if_fxp - the real point
On Wed, Mar 14, 2001 at 04:51:14PM -0500, Dennis wrote: Why would they need to do that? Every time you load a program it updates the libraries, breaking older programs. Its a philosophical problem. You dont need a grant to figure it out. You JUST DON'T GET IT [academic research]. And any attempt to explain it to you will obviously be wasted time. -- -- David ([EMAIL PROTECTED]) GNU is Not Unix / Linux Is Not UniX To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: optimizing apache with php and nfs mounts
On Wed, Mar 14, 2001 at 03:12:41PM -0800, Alex Zepeda wrote: Not untested -- but you should go grab a graduate text on compiler optimizations and familiarize yourself with the complexity of the problem. Care to recommend any starting places. You've piqued my interest. http://www.amazon.com/exec/obidos/ASIN/1558603204/ref=sim_books/107-1570516-8126104 Advanced Compiler Design and Implementation by Steven S. Muchnick (typical graduate text cost of $93.00!) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Parallel Programing in FreeBSD
Hi,
i'm trying to do some programming on freebsd and i can't
find 'asm/io.h'. this must be for security reasons.
so how do i talk to the parallel port?
Thanks,
Dave Seddon
here's the really simple bit of code i'm trying to use:
#include stdio.h
#include unistd.h /* needed for ioperm() */
#include asm/io.h /* for outb() and inb() */
#define DATA 0x378
#define STATUS DATA+1
#define CONTROL DATA+2
int main(void)
{
int x = 0x32;
int y = 0x08;
if (ioperm(DATA,3,1)) {
printf("Sorry, you were not able to gain access to the
ports\n");
printf("You must be root to run this program\n");
exit(1);
}
outb(DATA, x); /* Sends 0011 0010 to the Data Port */
outb(CONTROL, y^0x0b);
/* SELECT_IN = 1, INIT = 0, /AUTO_FEED = 0, /STROBE = 0 */
return (0);
}
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Parallel Programing in FreeBSD
* [EMAIL PROTECTED] [EMAIL PROTECTED] [010314 16:11] wrote: Hi, i'm trying to do some programming on freebsd and i can't find 'asm/io.h'. this must be for security reasons. so how do i talk to the parallel port? Thanks, Dave Seddon Generally it's a good idea to use "man -k" with a few choice keywords before mailing the lists: ~ % man -k ioperm i386_get_ioperm(2), i386_set_ioperm(2) - manage per-process access to the i386 I /O port space -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Parallel Programing in FreeBSD
Hi, i'm trying to do some programming on freebsd and i can't find 'asm/io.h'. this must be for security reasons. so how do i talk to the parallel port? See /usr/share/examples/ppi, and the ppi(4) manpage. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
device driver dev. book
Hi Readers, Does anyone of you know about a book that would deal specifically with FreeBSD device drivers dev.? If yes let me know. Most of the books in the field are written for Linux and so on. Thanks. Jerry. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Needs some autoconf + pthread + etc. clue
I'm trying to reduce the number of patches in one of my ports, but neither
I nor the author of the software knows the solution to this problem. The
patch I'm trying to eliminate is:
http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11/xscreensaver/files/patch-ab?rev=1.7
that refers to -lXmu -lXt and -lcom_err. I inherited that patch, so I'm
not sure it's strictly necessary, but I'm also not sure how to prove
conclusively that it isn't since the patch is kerberos related.
The other hack I'm trying to get rid of is in the Makefile:
post-patch:
@ ${CP} ${WRKSRC}/configure ${WRKSRC}/configure.Patched
@ ${SED} -e 's#-lpthread#-pthread#g' \
${WRKSRC}/configure.Patched ${WRKSRC}/configure
The author of xscreensaver is receptive to suggestions, and I'd hate for my
lack of clue in this area to hold back the effort to make this product
compile clean on freebsd.
Thanks,
Doug
--
Perhaps the greatest damage the American system of education has done
to its children is to teach them that their opinions are relevant
simply because they are their opinions.
Do YOU Yahoo!?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: httpfs
On Sat, Mar 10, 2001 at 03:15:15AM -0800, Kris Kennaway wrote: A few of us were talking on IRC tonight about how cool it would be to have an httpfs filesystem -- then it occurred to me we almost have this already, in the form of the (under-utilised) portalfs. Portalfs works by handing off everything to a userland daemon which handles the actual transaction request, so you could easily imagine extending it to provide an http method similar to the tcp method it currently has for initiating tcp connections. One could probably make this more generic and finish implementing the undocumented 'exec' method (which currently exists as a stub): this would run an administrator-specified command (i.e. fixed in /etc/portal.conf) and pipe the output back to the user. A fully navigable httpfs (e.g. one you can ls and cd around in) is more work and probably requires a full stacking layer, but this would still be pretty cool. Is anyone feeling inspired to implement this? :-) OK, as I've mentioned in a private mail to Kris several hours after he sent out this message, I've done some initial hacking on mount_portal which lets me put: http/ exec http/ /usr/bin/fetch fetch -q -o - http://$1- into /etc/portal.conf, and then do cat /p/http/www.FreeBSD.org/handbook/ (the $1- part refers to path components below /p/http/; $1- means 'path components from 1 to last, separated by /') The code still needs a lot of cleanup before I would dare submit it for review and comments; my question is, should I bother^W^W^Wdoes this look like a reasonable extension to mount_portal, or are there other ways/places that such functionality should be implemented, if at all? G'luck, Peter -- If the meanings of 'true' and 'false' were switched, then this sentence wouldn't be false. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
